Eric, > /foo - Only folks in the 'users' group can read, write and delete > files/dirs.
The permissions of directory foo do not influence whether someone can open a given file in it for reading or writing, only whether he can delete, create, or rename a file. Read permission for the directory means you can read what files are in it, e.g. issue the ls command and have filename completion. Once someone without read permission to a directory /knows/ the exact name of a file that's in it, however, he can write to, read, or execute that file if its permissions permit it. Precondition to do anything _at_all_ in the directory, however, is to have "execute" permission on it (even if you only want to "pass through" and do something in a subdirectory). Thus, the permissions of directory foo rule who is allowed to enter it at all (= "execute" permission), read its contents (the filenames and other information about the files) (= read permission), and who is allowed to create, rename, or delete files in it (= write permission). There are, however, two permission bits, which, when set on a directory, influence something beyond this: - the sticky bit, when set on a directory, has the effect of restricting write operations on the directory a little more: to delete or rename a file within it, it is no more enough to have write permission to the directory, but you have to be the owner of either the directory or the file (or the superuser, of course). - the setgid bit, when set on a directory, causes any new file created in it to take on the group ownership of the directory, rather than the default group of the user who created that file. Thus, for directory /foo, you need an ls -l output like this: dxrwxrw--- root users <date> foo (say 'chmod 770 /foo' and 'chgrp users /foo'). As far as I can see, this is the closest you can get to what you want: it allows the owner of the directory (arbitrarily root here) and members of the group users to create, rename, and delete files inside /foo, as well as get information _about_ the files in it. It excludes "the rest of the world" from doing anything inside it. > /bar - Only folks in the 'admin' group can read, write and delete > files/dirs. ditto: (say 'chmod 770 /bar' and 'chgrp admin /bar'. > For both: New files/dirs are created as owner=the person that > created it. This is always the case, AFAIK (no permission bit influences that). > New files/dirs are created as group='users'|'admin', respectively. Set the setgid bit: say 'chmod 2770 ...' instead of '770'. > User fred is in groups fred,user > User barney is in group barney > User betty is in groups betty,user,admin > > I'd like Betty to be able to read/write in both foo and bar. > Barney is hosed, he cannot read or write in neither foo nor bar > I'd like Fred to be able to read/write only in foo. That should be achieved here; I think your group assignment is logical. > I've tried logging in as betty and touching a new file in bar, but no > luck (permission denied), even when > drwxrwx--T 13 admin admin 4096 Nov 05 10:52 bar You have set the sticky bit ('chmod 1770 ...' instead of the setgid bit, ('chmod 2770 ...'). Permissions in ls -l output must be 'drwxrws---', not 'drwxrwx--T'. Compare with what is said above: If the sticky bit is set, betty must be either the owner of the directory (which is not the case: the owner is called admin), the owner of the file (apparently not her), or the superuser (apparently not). Hope this helps, Florian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]