[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rejecting users without entires in passwd



On Thu, Jul 10, 2003 at 02:11:51PM +0200, Hannah Schroeter wrote:

> There's /etc/pwd.db or /etc/spwd.db, where the usual routines take
> their information from. No need for linear search here, so no
> significant slowdown for 65k or more users.

IME, db files can be just as problematic. It's been a good four years since 
I last did it - has anybody got any performance stats for files with the 
number of users we're looking at here? I'd be interested in seeing real 
figures from an up-to-date example. I've only come back to running OBSD in 
the last week or after a "break" of some years so wasn't aware of 
/etc/pwd.db or /etc/spwd.db - I'm more used to the FreeBSD way of doing 
things at the moment.

Incidentally, as a completely seperate but related issue, there are other 
advantages to getting users out of the normal unix auth dbs providing you 
don't want to give them shell access:

- Generally easier to manage. If your users only exist in a SQL or LDAP
schema, you can normally quickly write tools to manage them and can extend
functionality (hours of use, determine soft quotas) by adding columns to the
schema. The choice of front-ends you can build your management system is 
extended and you can even do stuff that no amount of hacking would give you 
with traditonal unix auth - e.g. inherited user management rights so that I 
can give one user complete "root" control over a group of users he is 
responsible for. You get the idea. Your PHB would be impressed, but then 
he's probably stupid.

- It can be argued you're increasing security as you aren't giving out
usernames and passwords that could conceivably be used to get a shell on the
box. Setting the user's shell to a null shell is all well and good, but not
even having them in there at all protects you from being exploted through
file modification attacks. (sed s/\/sbin\/nologin/\/sbin\/tcsh/g)

The flip side:

- All your user's spools and web content end up with the same UID. If you're
handing out CGI or PHP access, you've effectively given one user the rights
to trash the rest of your user's sites, steal their DB passwords they may
have in config files, etc. Chroot'ing is not to be trusted for this, and in
some cases isn't possible. There are ways around this, but it's a whole
series of articles in itself.

- You can't give local users easy access to mail, web, and likewise these
"special" SQL-based users can't be given local shell access. All a bit
weird.

If you're an ISP though, it makes sense to go the LDAP/SQL way...

Anyway, interesting topic. One that has been ticking over in my head for at 
least 5 years now, and I'm starting to favour going back to standard unix 
authentication... maybe PAM is a good half-way house? :-)

-- 
Paul Robinson



Visit your host, monkey.org