Well, like most UNIX people, I'm lazy so here are a few articles that look to get the basics down:
For basic file permissions and octal representations but not including special attributes or ACLS:
http://www.perlfect.com/articles/chmod.shtmlhttp://www.mast.queensu.ca/~mastop/Unix/access-control.shtmlhttp://www.webmastervault.com/tip-chmod.shtmlThe above links only cover 3 of the 4 octal numbers regarding permissions that can be changed with "chmod". They only talk about the rwxrwxrwx portion. Well there is a 4th bit that controls whether the file is SUID/SGID and the "sticky" bit. And if you used octal notation this bit is actually the first of 4 numbers you would pass to "chmod" rather than the typical 3 numbers:
Normally to set a normal file rwxrwxrwx you would do either a "chmod a+rwx filename.dat" or in octal it would be "chmod 777 filename.dat". If you add the 4th octal it would be "chmod 0777 filename.dat" to get the same permissions. The first octal actually controls SUID and SGID. The same example above but with the "SUID" bit turned on in octal would be "chmod 4777 filename.dat", or "chmod u+s filename.dat" to add the SUID bit. I would have to strongly urge that you *NEVER* have a file with 4777 permissions. 4755 is common but 4777 would allow anyone to change the file and then execute it as the owner of the file (good trojan). However, Linux and hopefully other OSs will turn off the SUID bit after another person edits the file.
SUID means that when the file is run it will run with the permissions of the user that owns the file, no matter who executes it. Some *NIXs only allow the SUID on binary files but many allow it on scripts as well. The SGID bit means that when the program is run it will run and have the same rights as the group associated with the file, regardless of if the user running the program belongs to the group or not. The "sticky" bit is for directories. When you set a directory with permissions "1777" which means everyone has read/write/execute permissions to that directory and anyone can create files in that directory but only people who can delete a file from that directory are the owner of the file, the owner of the directory and "root". /tmp is set with the sticky bit on. It shows up with a "t" in the end of the permissions "drwxrwxrwt".
See
http://www.cs.umass.edu/rcfbbl/bbl_security_050395_utils.htmlAnother thing that I don't believe I saw mentioned in the above links is the fact that directories must be set "executable" (or have the "x" bit turned on) in order to be able to change into those directories (all parent directories above it must also be set executable). This is just a side note that can bite n00bies.
Now, ACLs (or Access Control Lists) allow restrictions or allowances on a file or directory above and beyond the basic UNIX (chmod) capabilities. For instance, you may want to make a directory owned by a particular user, and assign it to a specific group and give permissions to only the owner and group and no permissions for anyone else.
Say the /var/www/develop directory is owned by root and is assigned to the "www" group (chown root:www /var/www/develop). You have all of your web developers in the "www" group and they all must be able to change or add files to that directory but you want no one else messing with it. The directory would look like this:
drwxrwx--- root www size date time /var/www/develop
Now say you wanted to add user "joe" to this directory but not give him access to all of the other directories that the "www" group has access to. You can't add him to the "www" group and you don't want to have to create an entire other group just for this directory. Here's where ACLs come in. You can give it the above permissions, and add "rwx" for user "joe" and "r-x" for user "sally", etc, using the ACL editing tools.
Now most Linux distros do not come with ACL support, in fact I know of none, but they will be coming with it in the future. For now, you can download the ACL patch and the appropriate Kernel source and apply the patches, compile the kernel and install it. You'll also need the ACL modified fileutils and other packages.
See
http://acl.bestbits.at/I've applied the above patch and it works well, it even allows me to use NT domain users and extended ACL permissions on my files and shares that I have shared to windows machines using Samba.
This is "most" of what there is to know about file permissions but there is more. If you want to get into special files like pipes, sockets, etc, or if you wonder what the first letter you see in the permissions mean like "-","b","c","d","l", etc (as in "brw-rw---- root disk" on /dev/hda) I would surely be happy to discuss. And of course we did not discuss recursively changing permissions and the implications...
Have fun...
[ March 19, 2002: Message edited by: VoidMain ]
