      |
      |
       |
 |
back Commands: chown [user] [file] File Permissions: Each section is represented internally as three bits, which gives three on/off fields for each. For user, group, and other, the fields are: read - The user/group can read the contents of the file. For directories, this means the user/group can list its contents. write - The user/group can write to the file, changing the data in it however they want. For directories, it gives permission to create/remove files, so you can't actually DELETE a file unless you've got write perms to the directory its in. execute - The program can be run by the user/group. For directories, it means you can cd into the directory.
(Author's Note - If someone feels like writing up a good Symbolic Representations bit, E-Mail it to me and I'll throw it in here. The info pages are quite good, though.)
As each field of the file's permissions is three bits, it can be represented as a series of octal (base 8) numbers. The maximum base-10 value three bits can have is seven, which is the maximum value for a single digit in base 8. Read perms (bit 3) are represented by a 4. Write perms (bit 2) are represented by a 2. Execute perms (bit 1) are represented by a 1. To specify multiple permissions, just add their values together. For example, to specify read and write perms, you'd use a 6. To specify all of read, write, and execute, you'd use a 7. To specify none, use a 0. Now, to actually specify these, you use four digits. The first specifies extended file perms (covered below), and is almost always 0. The second specifies user permissions, the third group permissions, and the fourth world permissions. So to specify user read, write
and execute, group read and execute, and world read, you'd use: Commands:
Whenever a program is run, the permissions of the task it creates are set to the user and primary group of the user that runs it. What it can do is then limited by that. There are a bunch of rules about what it can then change its group and user permissions to, but they don't matter for the purposes of this discussion. Any good book/reference on Linux programming should provide more information. Sometimes, however, you want a program that ordinary users run to be able to do root-y things. Or you want something to always run as a certant user or group (for whatever reason). That's where the suid and sgid bits come in. If the suid bit is set on a program, that program will always run with the permissions of the user that owns it. The suid bit has no effect whatsoever on directories. Its the number 4 when using numeric file permissions. The sgid bit means it always runs with the permission of the group that owns it. It doesn't always have an effect for directories, but on some systems, it means that any files created in the directory are owned by the group that owns the directory, no matter what group the user created them as. The sgid bit is represented by 2 when using numeric file permissions. Both bits can, however, cause big huge gaping security holes if misapplied. So be extremely careful when using them - and never use them if there's a better way. There are supposed to be more finely-grained security levels that are being introduced at some point soon, but I haven't read anything about them for a long time. If anyone finds any information on this, E-Mail it to me and I'll add some links.
|