Re: file and directory permissions question...
On (06/11/03 14:39), lorian@fsavigny.de 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
Reply to: