On Fri, 2004-04-02 at 09:20, Ken Snider wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Robert P. J. Day wrote: > > | then why would you make "doe" a member of "staff" in the first place? > > Envision a "staff" only directory with ten files within. Nine of the ten > should be writable by all members of staff, save one, which should be writable > to everyone but user x. > > Should I make a new subgroup for "staff" now that includes everyone but x? > Does that paradigm carry forward if another file needs to be writable by x but > NOT by y (and creating yet another group)? > > Further, anytime you want a file to be written to by two different groups of > people, you have to create a union group of the two and have the file written > to by said new gid. What you just described is the "UNIX way" (tm) of doing things that has worked for 30 plus years. Ugly yes. Workable yes. A clean solution was devised many years ago called "POSIX file ACLs". Read the man page for setfacl and getfacl. Solaris adopted the feature in 1997, Linux (officially) with the 2.6 kernel. Obviously the features that POSIX file ACLs provides is a subset of what SELinux provides. I'm a fan of SELinux with it's way enforce the "correct behavior" of applications, but if you are just narrowly looking at the a solution for granular file permissions, then POSIX file ACLs are all you need. I suppose in a SELinux environment, POSIX file ACLs are redundant and uneeded (except for the "default permissions" (ala a custom umask) for a directory feature). Speaking of which, how does SELinux file permissions interact with a directory that has a default ACL applied? Dax Kelson Guru Labs
