Ok. I think I have a really hard head. Could someone please
explain to me the rationale behind the ``POSIX semantics'' that
have been bantered around in this thread?
Every time I re-read the capabilities POSIX docs I (aside from
getting a splitting headache) think that putting capabilities on
INODES as opposed to GIDs is braindead. I mean, really really
braindead.
The POSIX model leads to the modification of all of our file
systems, a lot of the user space utilities, and a BIG change in
how system administrators perform system inspection. We've already
hashed in the list the issues with find(1),tar(1),cpio(1) and other
utilities, but I think that's just the tip of the iceberg.
However, the capabilties-per-GID model seems (IMHO) to have a
lot going for it. If GIDs have default capability sets (and assuming
a GID for each major service a la ``http'',``man'',``ftp'',etc) then
you:
a) Have a centrialized, cross-filesystem way to inspect what
capabilites are used (/etc/capabilties in conjuct with /etc/group)
b) Don't have to modify tar/find/cpio/etc when you move to a
secure system.
c) System administrators can keep all their ``known to work in
the field'' knowledge about tracking SUID binaries.
I know that specs are ESSENTIAL to the Open Source project, and
I've been around since '92 on Linux, and I remember the big was over
BSD vs SYSV vs POSIX semantics back then. I also remember the extremly
prudent choice to go with POSIX. That was a positive turning point in
Linux development, and I applaud the POSIX standards committies for
(mostly) turning out extremly effective specifications.
However, I believe that POSIX DRAFT specs 1003.1e and 1003.2c
were withdrawn for good reason - they are unworkable in real life.
Since POSIX tends to document standard practice - when standard
practice leads to security, administrability, and maintainability -
I think that - on this one issue - we should lead the way.
Now, I'm all ready for the flames. Although, I would find it a
more convincing argument if you can tell me how the GID<->capabilities
model is less (1)secure, (2)administrable, (3)maintainable than the
POSIX DRAFT model, as opposed to simply pronouncing the work of the POSIX
committee - even withdrawn drafts - as the work of $DIETY.
-- Jason McMullan, Senior Linux Consultant, Linuxcare, Inc. 412.422.8077 tel, 415.701.0792 fax jmcmullan@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Support for the revolution.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:11 EST