On (06/11/03 14:39), [EMAIL PROTECTED] wrote: > 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). > Thanks Florian
I learn so much from this list ;) Regards Clive -- http://www.clivemenzies.co.uk strategies for business -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]