Ralf Ertzinger wrote: How is that a disadvantage, compared to existing systems? With previous systems, if you gain user priv you can also change user password. I think the idea of tcb is that's all you can do. No suid root stuff is used. (Honestly, I don't know much about tcb - I just thought it might be of interest)

On Thu, 24 Aug 2006, Neal Becker wrote: I think Ralf was thinking that tcb would permit something conceptually along the lines of $ vi /etc/tcb/`id -un`/shadow to change your existing passwd w/o having to know it The permissions on /etc/tcb should prevent that though -- only an sgid shadow app (the passwd command) can be used.... later, chris

On Thu, 24 Aug 2006, Ralf Ertzinger wrote: The advantages are that passwd, etc become sgid instead of suid, and that non-root users can only attack themselves through any passwd flaws.... later, chris

Once upon a time, Neal Becker <ndbecker2(a)gmail.com&gt; said: I can't see that right now (no text in that site), but I would say if it is anything like Tru64 Unix TCB, run away! -- Chris Adams <cmadams(a)hiwaay.net&gt; Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.

Once upon a time, Chris Ricker <kaboom(a)oobleck.net&gt; said: A little late on the reply here, but one problem I see is that it limits the number of local users. Since each user gets a direct subdirectory of /etc/tcb, you can only have as many users as you can have subdirectories (link count is 15 bits on ext2/3 IIRC, so 32767 users). Not everyone with lots of users has multiple servers, so NIS/LDAP are not automatically the answer. With a bunch of users, you could also run into performance problems with directory lookups (ext3 with hashed directories helps). A better method would be to do something like MD5 hash the username and then use the first two characters as directories. For example, "cmadams" hashes to "78dcb16738542f0a8853801c41757a70", so you could use "/etc/tcb/7/8/cmadams". Also, you've just given all users write access to the filesystem containing /etc (they can then fill it up, hard link to privileged files, etc.). I don't think you'd really want to give users ownership of the directory; that would bypass all password strength policies and such (the user could just overwrite their shadow file). Even if you keep the directories owned by root, users can still overwrite the contents of their shadow file entry with arbitrary content, which leads to all kind of possible attacks against daemons that read the file (e.g. how will sshd handle a 16000 byte shadow entry?). -- Chris Adams <cmadams(a)hiwaay.net&gt; Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.