[Proftpd-user] Use of and consequences of omitting 'userset'

Hi,

I hope someone can clear up the use of and consequences of omitting 
'userset' in mod_sql's SQLAuthenticate directive. Thank you in advance 
if you make it to the end of this email :).

First, context and my own research.

The documentation at http://www.proftpd.org/docs/howto/SQL.html says:

> Question: What is [...] the userset and usersetfast SQLAuthenticate 
> options [...] when would I use them?
> [...]
> First, the use of these options is only relevant when the session is 
> chrooted, either via the DefaultRoot
> directive or because it is an <Anonymous> login. (Why? When chrooting a 
> session, proftpd calls the setpwent()
> function in order to "reset" or "rewind" the user info database; this 
> ensures that all of the info in the user
> info database is accessible in the chrooted session.)

In other words: in a chroot, the user info database is made available by 
calling `setpwent`. Outside of a chroot, this is not needed.

This is confirmed by the documentation at 
http://www.proftpd.org/docs/contrib/mod_sql.html:

> If present, mod_sql will process the potentially expensive 
> {set|get|end}pwent() calls. If not present,
> mod_sql will not process these calls.

The documentation also says:

> The userset SQLAuthenticate option says that the info for all users 
> should be looked up and cached when
> setpwent() is called. Specifically, the list of names for every user in 
> the database (and just the names!) is
> looked up. For each user name, a SELECT query (using the SQLUserInfo 
> configuration) is used to retrieve all of
> the details for that user.

In other words: when 'userset' is set, when the chroot is started (= 
when setpwent() is called), 'all of the details' for 'every user in the 
database' are looked up and cached.

Put differently: when 'userset' is not set, no users are looked up. That 
means the username (`userid`), password (`passwd`), UID (`uid`), 
GID(`gid`), home directory (`home`) and shell path (`shell`) are not 
available in the chroot - although they are available outside of the 
chroot at the time of authentication. Makes perfect sense so far.

The question:

What I'm not completely clear on, is the consequences. The documentation 
at http://www.proftpd.org/docs/contrib/mod_sql.html does brush over this 
subject, saying:

> Turning off (i.e. by not including) the userset or groupset parameters 
> affects the functionality of mod_sql.
> Not allowing these lookups may remove the ability to control access or 
> control functionality by group
> membership, depending on your other authentication handlers and the 
> data available to them. At the same time,
> choosing not to do these lookups may dramatically speed login for many 
> large sites.

Some questions about that statement:

- Is it an example, or the only consequence?
- If an example, what consequences does omitting 'userset' have exactly?
- Does 'remove the ability to control access or control functionality by 
group membership' apply to 'userset', 'groupset', or both? (I can 
imagine it applies to 'groupset', because the groups table has a 
`members` column, although a user lookup might also lookup the groups 
it's a member of.)
- What is an 'authentication handler'? This terminology is nowhere to be 
found in the ProFTPD documentation. Are authentication modules meant by 
this (e.g. mod_auth_file)? If so, what is meant by "depending on your 
other authentication handlers and the data available to them"?

Met vriendelijke groeten,

William Edwards



_______________________________________________
ProFTPD Users List   <[email protected]>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html