In a message dated: Fri, 15 Feb 2002 12:28:23 EST
Jack Hodgson said:
>I confess that permissions is an aspect of linux/unix that
>I've always been a little fuzzy on, so I spent last night trying to
>learn more on that. But I'm not there yet.
For are really in depth discussion on UNIX permissions, check out the
Evi Nemeth book, "The UNIX System Administration Handbook".
I can probably give you a quick overview though, that should clear up
the basics of it.
There are 3 combinations of permissions:
Read
Write
Execute
These can be applied to files or directories. When applied to
directories, they have the following meanings:
Read You can "read" the contents of the directory
Write You can add/edit/delete contents of the directory, provided
the permissions of the file are in agreement
Execute You can 'cd' into the directory
If the permission on a directory have Execute set, but not Read,
you can 'cd' into the directory, but you can't look at the contents.
There are 3 "owners" to which the 3 permissions apply:
User The owner of the files
Group The "group" owner of the files, or "group" of people
who may (or may not) be allowed access to the files.
Other Everyone else who's not the owner and not a member of the
"group"
The combination of 3 permissions with the 3 "owners" provides 9
possible permission "bits" which can be set, and therefore translated
into binary representation:
r-- Read 100 = 400 = 4
-w- Write 010 = 020 = 2
--x Execute 001 = 001 = 1
rwx 111 = 421 = 7
Therefore, when all 3 permission "bits" are set on a file for one of
the 3 owners, it is said to be set to '7'.
Common "binary" settins are
644 rw-r--r--
755 rwxr-xr-x
711 rwx--x--x
444 r--r--r--
Each number is nothing more than a sum of the "bits" for that group.
With combinations of these basic permissions, you can pretty much
grant or deny access to/from anyone you need.
Some of the more esoteric "permissions" are the "Sticky Bit", the
"Set UID Bit" and the "Set GID" bit.
The sticky bit is hardly used anymore, but does occasionally come in
handy. It's traditional meaning no longer has any use, so I won't go
into it. Nowadays it's used in places like /var/spool/mail to allow
each person access to their own mailbox file, but prevent people from
deleting any file that's not their own.
The SUID and SGID bits are used for similar things. The SUID bit
allows someone to execute a file *as if* they were the owner.
The SGID bit allows someone to execute a file *as if* they were in
the group. Unless it's on a directory, in which case it forces the
permissions of all files and directories within to be the same as
that of the parent directory.
For example, if I have a directory "foo" with the following
permissions:
drwxr-x--- 6 pll eng 8192 Feb 6 12:20 foo
and I want all subsequent directories and files created within foo to
have the same permissions as foo itself, I would add the SGID bit to
the directory:
> chmod 6750 foo
> ls -ld foo
drwxr-s--- 6 pll eng 8192 Feb 6 12:20 foo
Note the permissions we set to *6* 750, not just 750. The 6 adds SGID
capability (and, consequently, 4 sets SUID capability).
So, now, anyone in the 'eng' group who creates a file or directory
within 'foo', will do so and maintain the 'foo' permissions:
> ls -l
> ls -la
total 16
drwsr-s--- 2 pll pll 4096 Feb 15 13:03 ./
drwxr-xr-x 97 pll pll 12288 Feb 15 13:02 ../
-rw-rw---- 1 pll pll 0 Feb 15 13:03 foo1
> mkdir foo2
> ls -la
total 20
drwsr-s--- 3 pll pll 4096 Feb 15 13:03 ./
drwxr-xr-x 97 pll pll 12288 Feb 15 13:02 ../
-rw-rw---- 1 pll pll 0 Feb 15 13:03 foo1
drwxrws--x 2 pll pll 4096 Feb 15 13:03 foo2/
Notice that the file 'foo1' has permissions set to 660, yet the
directory has permissions of 6771. That's my 'umask' is set to '006'.
So, that, combined with the SGID bit sets all files to 660, unless
it's a directory, then it turns on the 'x' bit so everyone can at
least 'cd' inside.
Much more information can be gleened from the Evi Nemeth book, and
the 'chmod' and 'umask' man pages.
I hope that helped!
--
Seeya,
Paul
----
God Bless America!
If you're not having fun, you're not doing it right!
...we don't need to be perfect to be the best around,
and we never stop trying to be better.
Tom Clancy, The Bear and The Dragon
*****************************************************************
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*****************************************************************
