|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Tuesday, 11 January 2000||Author: Kevin Fenzi|
|Published to: learn_articles_support/Articles||Page: 1/1 - [Printable]|
File Permissions Made Easy
Ext2.net's Kevin Fenzi, takes the time to explain File Permissions and Ownership in Unix File Systems
|Page 1 of 1|
Ext2's Original Publishing of this article can be found here.
Unix separates access control on files and directories according to three characteristics: owner, group, and other. There is always exactly one owner, any number of members of the group, and everyone else.
A quick explanation of Unix permissions:
Ownership - Which user(s) and group(s) retain(s) control of the permission settings of the node and parent of the node
Permissions - Bits capable of being set or reset to allow certain types of access to it. Permissions for directories may have a different meaning than the same set of permissions on files.
+o To be able to view contents of a file
+o To be able to read a directory
+o To be able to add to or change a file
+o To be able to delete or move files in a directory
+o To be able to run a binary program or shell script
+o To be able to search in a directory, combined with read permission
Save Text Attribute: (For directories)
The "sticky bit" also has a different meaning when applied to directories than when applied to files. If the sticky bit is set on a directory, then a user may only delete files that the he owns or for which he has explicit write permission granted, even when he has write access to the directory. This is designed for directories like /tmp, which are world-writable, but where it may not be desirable to allow any user to delete files at will. The sticky bit is seen as a t in a long directory listing.
SUID Attribute: (For Files)
This describes set-user-id permissions on the file. When the set user ID access mode is set in the owner permissions, and the file is executable, processes which run it are granted access to system resources based on user who owns the file, as opposed to the user who created the process. This is the cause of many "buffer overflow" exploits.
SGID Attribute: (For Files)
If set in the group permissions, this bit controls the "set group id" status of a file. This behaves the same way as SUID, except the group is affected instead. The file must be executable for this to have any effect.
SGID Attribute: (For directories)
If you set the SGID bit on a directory (with chmod g+s directory), files created in that directory will have their group set to the directory's group.
You - The owner of the file
Group - The group you belong to
Everyone - Anyone on the system that is not the owner or a member of the group
-rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin 1st bit - directory? (no) 2nd bit - read by owner? (yes, by kevin) 3rd bit - write by owner? (yes, by kevin) 4th bit - execute by owner? (no) 5th bit - read by group? (yes, by users) 6th bit - write by group? (no) 7th bit - execute by group? (no) 8th bit - read by everyone? (yes, by everyone) 9th bit - write by everyone? (no) 10th bit - execute by everyone? (no)
The following lines are examples of the minimum sets of permissions that are required to perform the access described. You may want to give more permission than what's listed here, but this should describe what these minimum permissions on files do:
-r-------- Allow read access to the file by owner --w------- Allows the owner to modify or delete the file (Note that anyone with write permission to the directory the file is in can overwrite it and thus delete it) ---x------ The owner can execute this program, but not shell scripts, which still need read permission ---s------ Will execute with effective User ID = to owner --------s- Will execute with effective Group ID = to group -rw------T No update of "last modified time". Usually used for swap files ---t------ No effect. (formerly sticky bit)
drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/ 1st bit - directory? (yes, it contains many files) 2nd bit - read by owner? (yes, by kevin) 3rd bit - write by owner? (yes, by kevin) 4th bit - execute by owner? (yes, by kevin) 5th bit - read by group? (yes, by users 6th bit - write by group? (no) 7th bit - execute by group? (yes, by users) 8th bit - read by everyone? (yes, by everyone) 9th bit - write by everyone? (no) 10th bit - execute by everyone? (yes, by everyone)
The following lines are examples of the minimum sets of permissions that are required to perform the access described. You may want to give more permission than what's listed, but this should describe what these minimum permissions on directories do:
dr-------- The contents can be listed, but file attributes can't be read d--x------ The directory can be entered, and used in full execution paths dr-x------ File attributes can be read by owner d-wx------ Files can be created/deleted, even if the directory isn't the current one d------x-t Prevents files from deletion by others with write access. Used on /tmp d---s--s-- No effect
System configuration files (usually in /etc) are usually mode 640 (-rw-r-----), and owned by root. Depending on your sites security requirements, you might adjust this. Never leave any system files writable by a group or everyone. Some configuration files, including /etc/shadow, should only be readable by root, and directories in /etc should at least not be accessible by others.
Set UID SHELL scripts:
SUID shell scripts are a serious security risk, and for this reason the kernel will not honor them. Regardless of how secure you think the shell script is, it can be exploited to give the cracker a root shell.
|Page 1 of 1|