In article <3DF67E75.90801@mukappabeta.de>, Matthias Buelow wrote:
> Alan Post wrote:
> 
>> If you can write to /etc/userdb/apost/homedir, then you must have
>> access to my files already, so how is this a new problem?
> 
> I always found it a bit reassuring that nobody could change my
> password (except for root of course) just because I happened to turn
> my back for a couple seconds, even if he was logged in under my
> user-id.

But that person *can* trojan your init scripts while your back is
turned.

> This (apart from the quota issue) also seems to be reflected in not
> being able (today) to chown a file to another user (otherwise, one
> could easily copy /bin/sh to somewhere, chown it to the user, and
> set the suid bit.)  It's just another simple security-enhancing
> mechanism that might be handy in some situations.

The problem you mention is an illustration of why setuid is a bad OS
feature.  My primary motivation in trying to find a different user db
was to remove setuid programs.

> Also, as already mentioned, there's the issue of performance.  And
> if you've got tens of thousands of users in your local passwd
> (which, admittedly, probably isn't all too common anymore these
> days) that would mean a _lot_ of files for /etc/userdb; which
> probably would slow down access to that directory significantly, not
> to speak about the many inodes that would have to be available for
> that (I for example prefer a very small root-directory.)  Of course
> people who want to accomodate so many users could certainly use
> different parameters for sizing their filesystems but still.

As you say, this is not so common.  Those people can use some fast DB
for lookups that requires a daemon or setuid program to maintain.  The
rest of us can use a simple, nonsetuid user db.

  Alan