Re:

[Terry Lambert <terry@whistle.com>]

Fletcher E Kittredge wrote:
>         I think trying to hack application specific LDAP
> code will end up being more work than necessary, and be
> less reliable that is possible.  What you really want is
> to get the whole OS to use LDAP.  Then, all legacy
> applications will work together.  There is also less
> likelihood that you will open some horrific security hole.

The problems with this, as I see them, are:

o	He wanted to have virtual users that didn't have
	login access to the machine.  Full LDAP integration
	turns these users into real users, not just email
	and web hosting accounts.

o	The IRS and NSS are for name services (IRS=Information
	Retrieval Service, NSS=Name Server Switch); I think
	you probably meant to suggest PAM_LDAP instead.

o	He wanted integrated quota enforcement.  This
	requires either a Heidemann stacking FS layer for
	the implementation of quotas, with upcalls to a
	user space daemon (there are vm_object_t coherency
	problems with the current stacking implementation
	in all BSD 4.4 derviced OSs, so this is not really
	an option), or it requires real user credentials.
	This is because the quotas are stored in a file
	using kernel level file I/O, and the quota is keyed
	off the UNIX UID (in the old code, this was a 16 bit
	value; in the current code, it's a 32 bit value).
	In addition, the RFC 2307 LDAP schema doesn't include
	quota information, so it would have to be an extension
	attribute.

I believe that the best approach currently available to him
would be to enable quotas on the FS in question, and then
modify the FTP daemon to:

1)	Use PAM_LDAP (I believe he said he already had
	this), and

2)	Make FTP seteuid() to the PAM_LDAP returned UID,
	after carving out a chunk of the UNIX UID space
	for his own use (e.g. "all users UID 1000 or
	greater are LDAP-based virtual users, and the
	system will not create accounts with UID > 999").
	The range should not start too high, since the
	quota file is sparse, and backup may become an
	issue otherwise; and

3)	The quota settings per account go in the quota
	file, not into the LDAP directory.  This is a bit
	annoying when you first consider it, but the
	alternative is blocking FS requests pending a
	user space daemon responding to the quota data
	changes, and doing a lot of non transaction-locked
	writes to your LDAP directory, which is mostly
	expecting only reads, since LDAP is not LTAP.

FWIW, I am using LDAP for routing of email which is then
stored in replicated Cyrus servers.  The Cyrus servers
do their own quota enforcement (Cyrus does this in the
"deliver" program it provides to enable Cyrus to replace
local mailer delivery).  I use the same directory for
routing that I use for Cyrus daemon login, and that I use
for authentication to a Web UI.

IMO, there's really no difference between having the Cyrus
"deliver" program enforce the mail quota, and having the
file system disk quota code enforce the FTP quota.

This is clearly not as integrated as if you stored the
quota in the directory, and did quota accounting on quota
change events by writing back to the directory; on the
other hand, LDAP is not really built for doing the needed
transaction-locked changes to the currently consumed
portion of the quota, which is highly variable.

As always, your mileage may vary; but I'm pretty certain
that the FTP server had the PAM_LDAP supplied UID from
the RFC 2307 schema, even if it's not (currently) simply
calling seteuid() after recontacting the LDAP server to
look up the UID of the user returned by pam_get_user().


-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- terry@whistle.com
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.