Subject: Re: passwd file vs PAM

From: Philip Gwyn <[email-masked]>
Date: Sat, 06 Dec 1997 00:28:53 -0500

At 10:19 PM 12/5/97 -0600, kent wrote:
>Implementing PAM would require total rewrites to the user authentication
>section to accomadate it.  This is not something that I have time for at
>the present time.  I do have time for the wrapper extensions as there are
>so few places that I have to replace calls and so little code to write.
>
>PAM is a good idea. This is exactly the type of thing I was talking about
>the other day when I said things need to start moving faster.  I'd really
>like to see it done but I have a problem to solve. And from the non-reaction
>I received from my rant it doesn't look as if I'm going to get much help.
>So I'll do it this way for now. If I'm the only one using it, so be it.
>When people find time to think about doing it right we'll probably find a
>near total code reorg is in order.

I must have missed your original posting.  I agree with you that WU needs a
serious looking to.  Something on the order of what Apache did to NCSA.
And I would really like to help in this work.  The problem is I have no
spare time.  I'm behind in my regular work schedule and probably won't have
any spare time until next spring.  I was hoping to use WU in one of my
current projects.  That way I could be paid to put some work in.  I decided
to go with HTTP and NPH-CGI instead.

My highly personal wish-list:
Better config file format
Better error logging.  (If ls or zip won't work, I need an error as to why,
damn it!  And trafic on this list would plummet! -:)
Common log format (ie access_log) log files would be cool

Things that would be useful:
Stand-alone server w/ threading
PAM
Expansion module capability

While we're dreaming, why not:
CGI-like capabilities (get a file, said-file is executed, output is
transmited.  The problem now is, how do you transfer the file contents, not
it's output? -:)
transfer-triggered execution (transfer a file too/from a directory, trigger
external program before and/or after)
.ftaccess files, operating like .htaccess

As I see it, we first need the new config files and a stand-alone server.
Then we could write the expansion module stuff.  Stand-alone server comes
first because parsing the config files and loading the expansion modules at
each invocation would be a bad performance hit.  After that, we can run
wild with writing modules.

Then again, could one write an FTP module for Apache and leverage their
code-base?  Or even just grab Apache, gut out all the HTTP stuff and use it
as a squeleton?  (Remember, I'm in dream-on mode -:)

I have yet to really look at the source code.  I have no idea what state
it's in nor how much work or reworking it would take to get any of this
done.  Provoked by an article in Linux Journal, I've thought about PAM a
bit.  One complication I see is the chrooting business and how it would
relate to pam_open_session(1).  In fact we might have to write a PAM module
to take care of guest users, anonymous users and the "virtual" users you're
working on.  

>If this sounds bad I apologize. It was not meant to.  It's been a long day
and
>I nearly have the wrappers done...
Hey, no worries.  I've had a bad week too.  I find a St-Ambroise Oatmeal
Stout helps.

-Philip

-----------------------------
"If what you say is true, Shaolin kung-fu and Wu-Tang sword style could be
very dangerous."

---

From: [email-masked]
Date: Sat, 6 Dec 1997 01:31:50 -0500 (EST)

>  >near total code reorg is in order.

[...]

>  to take care of guest users, anonymous users and the "virtual" users you're

Hey guys!  Wu-ftpd already works with PAM.  That is exactly what Redhat
ships on their CD and is available at their ftp site.  The pam module
doesn't provide support for virtual domains but it is there and it does
work.  ...works quite well in fact.

Cheers!
Ty

-- 
Tyson D Sawyer                     Real World Interface, Inc.
Senior Systems Engineer            Robots for the Real World
[email-masked]                   http://www.rwii.com/