RE: [Proftpd-devel] Oracle, Single-User, with Multiple chroot() Directories

[TJ S. <tj...@ca...>]

djarvi>Right.  Ideally, I'm looking for the following:
djarvi>
djarvi><Global>
djarvi>	UserDirRoot /ftp/public/$USER
djarvi></Global>

How about a UserHome (similar to UserPassword), that honors $USER?

djarvi>Should these be split apart?  Figuring out what user owns
djarvi>the process, and knowing where to chroot() should be
djarvi>independent of the user that is logging in -- and separate
djarvi>entities themselves.  Loosening the requirement that the
djarvi>account information must reside on the same machine as the
djarvi>FTP daemon itself is definitely a bonus.  Doesn't LDAP do
djarvi>this?

The reason the process/user credentials and the home directory are so
tightly linked at the moment is that all the necessary information is
stored in a single struct, struct passwd, and retrieved with a single
function, auth_getpwnam().

Auth modules such as mod_ldap and mod_sql do indeed use the Authentication
layer to supply account information from (possibly) remote sources.  With
proftpd's API having the account information on the host machine is not a
requirement.

djarvi>1) I make two static structures with values as defined above.
djarvi>2) I override getXXX, setXXX, and endXXX functions to use the values defined
djarvi>above (which causes the correct process permissions to spawn, and chroot()'s
djarvi>to the proper location).
djarvi>3) I override "auth" to perform the database validation based on given user
djarvi>name and password.

You'll want to provide auth handlers for all of the authtab slots,
including "check" -- mod_unixpw uses all of them, if I recall correctly.

djarvi>How do I cause a username that doesn't exist to be ignored?
djarvi>It doesn't exist locally, but may exist inside the database
djarvi>(though not necessarily).

How do you mean "ignored", exactly?  If your auth handler returns ERROR
for some username, the auth dispatch cycle stops there, and the user
probably won't be able to log in.  If it returns DECLINED, then other auth
handlers (for other account sources) have a chance to resolve that
username...

djarvi>It's a nice idea; hardcoding or relying on values from a
djarvi>specific source is bad (insofar is flexible API/libraries
djarvi>are concerned).  It's like the difference between using a
djarvi>URL as a data source and an input stream.  The input stream
djarvi>provides a higher degree of flexibility because it could be
djarvi>a file, console input, large database object, FTP download,
djarvi>or HTTP data.  The function doesn't care, and shouldn't
djarvi>know; it's the responsibility of the calling function to
djarvi>figure out how to point to the start of the data.

On a related note, one API I'd like to see added to the 1.3 source is the
Confstream API, mentioned under the "Experimental APIs" on

  http://www.castaglia.org/proftpd/

djarvi>Likewise, the core API should be told the chroot() directory
djarvi>independent of what account is logging in, without depending
djarvi>on an external source.  It just so happens that nearly all
djarvi>the time they'll be closely related.  :-)

I think the proposed UserHome directive may neatly solve this.  If you
agree, I can have a patch for this in about an hour...

TJ

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   I hate and I love: why I do so you may well ask.  I do not know, but I feel
   it happen and am in agony.

   	-Catullus

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~