Re: file and directory permissions question...
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--- rootusersdate 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]
Re: file and directory permissions question...
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--- rootusersdate 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]
file and directory permissions question...
Hi All, I'm trying to set up some restrictions to a couple of directories and their files and just can't seem to get it right. Here's what I'm trying to do: /foo - Only folks in the 'users' group can read, write and delete files/dirs. /bar - Only folks in the 'admin' group can read, write and delete files/dirs. For both: New files/dirs are created as owner=the person that created it. New files/dirs are created as group='users'|'admin', respectively. 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. 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 Can someone enlighten me with a chmod command or two that'll make this happen? Do I need to change the groups to which the users belong? It probably doesn't matter, but I'm running Debain 'unstable'. Many thanks in advance. Eric. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
