[2024-feb-29] Sad news: Eric Layton aka Nocturnal Slacker aka vtel57 passed away on Feb 26th, shortly after hospitalization. He was one of our Wiki's most prominent admins. He will be missed.

Welcome to the Slackware Documentation Project

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
slackbook:filesystem_permissions [2012/09/03 17:07 (UTC)] – added tags mfillpotslackbook:filesystem_permissions [2012/10/15 22:28 (UTC)] (current) – [SUID, SGID, and the Sticky Bit] gerardo.zamudio
Line 4: Line 4:
 ===== Permissions Overview ===== ===== Permissions Overview =====
  
-As we've discussed, Slackware Linux is a multi-user operating system. Because of this, its filesystems are mutli-user as well. This means that every file or directory has a set of permissions that can grant or deny privileges to different users. There are three basic permissions and three sets of permissions for each file. Let's take a look at an example file.+As we've discussed, Slackware Linux is a multi-user operating system. 
 +Because of this, its filesystems are mutli-user as well. This means 
 +that every file or directory has a set of permissions that can grant or 
 +deny privileges to different users. There are three basic permissions 
 +and three sets of permissions for each file. Let's take a look at an 
 +example file. 
  
 <code> <code>
Line 11: Line 17:
 </code> </code>
  
-Recall from chapter 4 that ls [-llists the permissions for a file or directory along with the user and group that "own" the file. In this case, the permissions are rwxr-xr-x, the user is root and the group is also root. The permissions section, while grouped together, is really three seperate pieces. The first set of three letters are the permissions granted to the user that owns the file. The second set of three are those granted to the group owner, and the final three are permissions for everyone else.+ 
 +Recall from chapter 4 that **//ls//** //-l// 
 +lists the permissions for a file or 
 +directory along with the user and group that //"own"// the file. In this 
 +case, the permissions are rwxr-xr-x, the user is root and the group is 
 +also root. The permissions section, while grouped together, is really 
 +three separate pieces. The first set of three letters are the 
 +permissions granted to the user that owns the file. The second set of 
 +three are those granted to the group owner, and the final three are 
 +permissions for everyone else. 
  
 **Table 10.1. Permissions of /bin/ls** **Table 10.1. Permissions of /bin/ls**
Line 20: Line 36:
 |Others |r-x |Everyone else may read and execute| |Others |r-x |Everyone else may read and execute|
  
-The permissions are pretty self explainatory of course, at least for files. Read, write, and execute allow you to read a file, write to it, or execute it. But what do these permissions mean for directories? Simply put, the read permissions grants the ability to list the directory's contents (say with ls). The write permission grants the ability to create new files in the directory as well as delete the entire directory, even if you otherwise wouldn't be able to delete some of the other files inside it. The execute permission grants the ability to actually enter the directory (with the bash built-in command cd for example).+The permissions are pretty self explanatory of course, at least for 
 +files. Read, write, and execute allow you to read a file, write to it, 
 +or execute it. But what do these permissions mean for directories? 
 +Simply put, the read permissions grants the ability to list the 
 +directory's contents (say with **//ls//**). The write 
 +permission grants the ability to create new files in the directory as 
 +well as delete the entire directory, even if you otherwise wouldn't be 
 +able to delete some of the other files inside it. The execute 
 +permission grants the ability to actually enter the directory (with the 
 +**//bash//** built-in command cd for example). 
  
 Let's look at the permissions on a directory now. Let's look at the permissions on a directory now.
 +
  
 <code> <code>
Line 29: Line 56:
 </code> </code>
  
-Here we see the permissions on my home directory and its ownership. The directory is owned by the user alan and the group users. The user is granted all rights (rwx), the group is granted only read and execute permissions (r-x), and everyone else is prohibited from doing anything. 
  
 +Here we see the permissions on my home directory and its ownership. The
 +directory is owned by the user alan and the group users. The user is
 +granted all rights (rwx), the group is granted only read and execute
 +permissions (r-x), and everyone else is prohibited from doing anything.
 ===== chmod, chown, and chgrp ===== ===== chmod, chown, and chgrp =====
  
-So now that we know what permissions are, how do we change them? And for that matter, how do we assign user and group ownership? The answer is right here in this section.+So now that we know what permissions are, how do we change them? And 
 +for that matter, how do we assign user and group ownership? The answer 
 +is right here in this section
 + 
 + 
 +The first tool we'll discuss is the useful 
 +**//chown//** 
 +(1) command. Using **//chown//**, we can (you guessed 
 +it), change the ownership of a file or 
 +directory.  **//chown//** is historically used only 
 +to change the user ownership, but can change the group ownership as well.
  
-The first tool we'll discuss is the useful chown (1) command. Using chown, we can (you guessed it), change the ownership of a file or directory. chown is historically used only to change the user ownership, but can change the group ownership as well. 
  
 <code> <code>
Line 49: Line 88:
 </code> </code>
  
-By using a colon after the user account, you may also specify a new group account.+ 
 +By using a colon after the user account, you may also specify a new 
 +group account. 
  
 <code> <code>
Line 59: Line 101:
 </code> </code>
  
-chown can also be used recursively to change the ownership of all files and directories below a target directory. The following command would change all the files under the directory ///tmp/foo// to have their ownership set to root:root.+ 
 +**//chown//** can also be used recursively to change 
 +the ownership of all files and directories below a target directory. 
 +The following command would change all the files under the directory 
 +''/tmp/foo'' to have their ownership set to root:root. 
  
 <code> <code>
-darkstar:~# chown -R root:root /tmp/foo/b +darkstar:~# chown -R root:root /tmp/foo/b</code> 
-</code>+ 
 + 
 +Specifying a colon and a group name without a user name will simply 
 +change the group for a file and leave the user ownership intact.
  
-Specifying a colon and a group name without a user name will simply change the group for a file and leave the user ownership intact. 
  
 <code> <code>
Line 76: Line 125:
 </code> </code>
  
-The younger brother of chown is the slightly less useful chgrp(1). This command works just like chown, except it can only change the group ownership of a file. Since chown can already do this, why bother with chgrp? The answer is simple. Many other operating systems use a different version of chown that cannot change the group ownership, so if you ever come across one of those, now you know how. 
  
-There's a reason we discussed changing ownership before changing permissions. The first is a much easier concept to grasp. The tool for changing permissions on a file or directory is chmod(1). The syntax for it is nearly identical to that for chown, but rather than specify a user or group, the administrator must specify either a set of octal permissions or a set of alphabetic permissions. Neither one is especially easy to grasp the first time. We'll begin with the less complicated octal permissions.+The younger brother of **//chown//** is the 
 +slightly less useful **//chgrp//**(1). This 
 +command works just like **//chown//**, except 
 +it can only change the group 
 +ownership of a file. Since **//chown//** can 
 +already do this, why bother with 
 +**//chgrp//**? The answer is simple. Many other 
 +operating systems use a 
 +different version of **//chown//** that cannot 
 +change the group ownership, so 
 +if you ever come across one of those, now you know how. 
 + 
 + 
 +There's a reason we discussed changing ownership before changing 
 +permissions. The first is a much easier concept to grasp. The tool for 
 +changing permissions on a file or directory is 
 +**//chmod//**(1). The syntax for it 
 +is nearly identical to that for **//chown//**, but 
 +rather than 
 +specify a user or group, the administrator must specify either a set of 
 +octal permissions or a set of alphabetic permissions. Neither one is 
 +especially easy to grasp the first time. We'll begin with the less 
 +complicated octal permissions
 + 
 + 
 +Octal permissions derive their name from being assigned by one of eight 
 +digits, namely the numbers 0 through 7. Each permissions is assigned a 
 +number that is a power of 2, and those numbers are added together to 
 +get the final permissions for one of the permission sets. If this 
 +sounds confusing, maybe this table will help
  
-Octal permissions derive their name from being assigned by one of eight digits, namely the numbers 0 through 7. Each permissions is assigned a number that is a power of 2, and those numbers are added together to get the final permissions for one of the permission sets. If this sounds confusing, maybe this table will help. 
  
 **Table 10.2. Octal Permissions** **Table 10.2. Octal Permissions**
Line 88: Line 164:
 |Execute |1| |Execute |1|
  
-By adding these values together, we can reach any number between 0 and 7 and specify all possible permission combinations. For example, to grant both read and write privilages while denying execute, we would use the number 6. The number 3 would grant write and execute permissions, but deny the ability to read the file. We must specify a number for each of the three sets when using octal permissions. It's not possible to specify only a set of user or group permissions this way for example.+By adding these values together, we can reach any number between 0 and 
 +7 and specify all possible permission combinations. For example, to 
 +grant both read and write privileges while denying execute, we would 
 +use the number 6. The number 3 would grant write and execute 
 +permissions, but deny the ability to read the file. We must specify a 
 +number for each of the three sets when using octal permissions. It's 
 +not possible to specify only a set of user or group permissions this 
 +way for example. 
  
 <code> <code>
Line 98: Line 182:
 </code> </code>
  
-chmod can also use letter values along with + or to grant or deny permissions. While this may be easier to remember, it's often easier to use the octal permissions.+ 
 +**//chmod//** can also use letter values along with 
 +<key>'+'</key> or <key>Minus</key> to grant or deny permissions. 
 +While this may be easier to 
 +remember, it's often easier to use the octal permissions.  
  
 **Table 10.3. Alphabetic Permissions** **Table 10.3. Alphabetic Permissions**
Line 112: Line 201:
 |Others/World |o| |Others/World |o|
  
-To use the letter values with chmod, you must specify which set to use them with, either "u" for user, "g" for group, and "o" for all others. You must also specify whether you are adding or removing permissions with the "+" and "-" signs. Multiple sets can be changed at once by seperating each with a comma.+To use the letter values with **//chmod//**, you 
 +must specify which set to use them with, either //"u"// for user, //"g"// for 
 +group, and //"o"// for all others. You must also specify whether you are 
 +adding or removing permissions with the //"+"// and //"-"// signs. Multiple 
 +sets can be changed at once by separating each with a comma. 
  
 <code> <code>
Line 132: Line 226:
 </code> </code>
  
-Which you prefer to use is entirely up to you. There are places where one is better than the other, so a real Slacker will know both inside out. 
  
 +Which you prefer to use is entirely up to you. There are places where
 +one is better than the other, so a real Slacker will know both inside
 +out.
 ===== SUID, SGID, and the "Sticky" Bit ===== ===== SUID, SGID, and the "Sticky" Bit =====
  
-We're not quite done with permissions just yet. There are three other "special" permissions in addition to those mentioned above. They are SUID, SGID, and the sticky bit. When a file has one or more of these permissions set, it behaves in special ways. The SUID and SGID permissions change the way an application is run, while the sticky bit restricts deletion of files. These permissions are applied with chmod like read, write, and execute, but with a twist.+We're not quite done with permissions just yet. There are three other 
 +//"special"// permissions in addition to those mentioned above. They are 
 +SUID, SGID, and the sticky bit. When a file has one or more of these 
 +permissions set, it behaves in special ways. The SUID and SGID 
 +permissions change the way an application is run, while the sticky bit 
 +restricts deletion of files. These permissions are applied with 
 +**//chmod//** 
 +like read, write, and execute, but with a twist
 + 
 + 
 +SUID and SGID stand for //"Set User ID"// and //"Set Group ID"// respectively. 
 +When an application with one of these bits is set, the application runs 
 +with the user or group ownership permissions of that application 
 +regardless of what user actually  
 +executed it. Let's take a look at a common SUID application, the humble 
 +**//passwd//** and the files it modifies.
  
-SUID and SGID stand for "Set User ID" and "Set Group ID" respectively. When an application with one of these bits is set, the application runs with the user or group ownership permissions of that application regardless of what user actually executed it. Let's take a look at a common SUID application, the humble passwd and the files it modifies. 
  
 <code> <code>
Line 149: Line 259:
 </code> </code>
  
-Notice the permissions on passwd. Instead of an x in the user's execute slot, we have an s. This tells us that passwd is a SUID program, and when we run it, the process will run as the user "root" rather than as the user that actually executed it. The reason for this is readily apparent as soon as you look at the two files it modifies. Neither /etc/passwd nor /etc/shadow are writeable by anyone other than root. Since users need to change their personal information, passwd must be run as root in order to modify those files. 
  
-So what about the sticky bit? The sticky bit restricts the ability to move or delete files and is only ever set on directories. Non-root users cannot move or delete any files under a directory with the sticky bit set unless they are the owner of that file. Normally anyone with write permission to the file can do this, but the sticky bit prevents it for anyone but the owner (and of course, root). Let's take a look at a common "sticky" directory.+Notice the permissions on **//passwd//**. Instead of 
 +an <key>'x'</key> in the user's execute slot, we have an 
 +<key>'s'</key>. This tells us that 
 +**//passwd//** is a SUID program, and when we run 
 +it, the process will run as the user //"root"// rather than as the user 
 +that actually executed it. The reason for this is readily apparent as 
 +soon as you look at the two files it modifies. Neither 
 +''/etc/passwd'' nor ''/etc/shadow'' 
 +are writable by anyone other than root. Since users need to change 
 +their personal information, **//passwd//** must be 
 +run as root in order to modify those files. 
 + 
 + 
 +So what about the sticky bit? The sticky bit restricts the ability to 
 +move or delete files and is only ever set on directories. Non-root 
 +users cannot move or delete any files under a directory with the sticky 
 +bit set unless they are the owner of that file. Normally anyone with 
 +write permission to the file can do this, but the sticky bit prevents 
 +it for anyone but the owner (and of course, root). Let's take a look at 
 +a common //"sticky"// directory.  
  
 <code> <code>
Line 158: Line 287:
 </code> </code>
  
-Naturally, being a directory for the storage of temporary files sytem wide, /tmp needs to be readable, writeable, and executable by anyone and everyone. Since any user is likely to have a file or two stored here at any time, it only makes good sense to prevent other users from deleting those files, so the sticky bit has been set. You can see it by the presence of the **t** in place of the **x** in the world permissions section.+ 
 +Naturally, being a directory for the storage of temporary files system 
 +wide, ''/tmp'' needs to be readable, writable, and 
 +executable by anyone and everyone. Since any user is likely to have a 
 +file or two stored here at any time, it only makes good sense to 
 +prevent other users from deleting those files, so the sticky bit has 
 +been set. You can see it by the presence of the <key>'t'</key> in 
 +place of the <key>'x'</key> in the world permissions section. 
  
 **Table 10.5. SUID, SGID, and "Sticky" Permissions** **Table 10.5. SUID, SGID, and "Sticky" Permissions**
-^Permission ^Type ^Octal Value ^Letter Value|+^Permission Type ^Octal Value ^Letter Value|
 |SUID |4 |s| |SUID |4 |s|
 |SGID |2 |s| |SGID |2 |s|
 |Sticky |1 |t| |Sticky |1 |t|
  
-When using octal permissions, you must specify an additional leading octal value. For example, to recreate the permission on /tmp, we would use 1777. To recreate those permissions on /usr/bin/passwd, we would use 4711. Essentially, any time this leading fourth octet isn't specified, chmod assumes its value to be 0.+When using octal permissions, you must specify an additional leading 
 +octal value. For example, to recreate the permission on 
 +''/tmp'', we would use 1777. To recreate those 
 +permissions on ''/usr/bin/passwd'', we would use 4711. 
 +Essentially, any time this leading fourth octet isn't specified, 
 +**//chmod//** assumes its value to be 0. 
  
 <code> <code>
Line 173: Line 316:
 </code> </code>
  
-Using the alphabetic permission values is slightly different. Assuming the two files above have permissions of 0000 (no permissions at all), here is how we would set them.+ 
 +Using the alphabetic permission values is slightly different. Assuming 
 +the two files above have permissions of 0000 (no permissions at all), 
 +here is how we would set them.  
  
 <code> <code>
Line 180: Line 327:
 </code> </code>
  
 +====== Chapter Navigation ======
 +
 +**Previous Chapter: [[slackbook:users|Users and Groups]]**
 +
 +**Next Chapter: [[slackbook:working_with_filesystems|Working with Filesystems]]**
 ====== Sources ====== ====== Sources ======
 <!-- If you copy information from another source, then specify that source --> <!-- If you copy information from another source, then specify that source -->
- * Original source: [[http://www.slackbook.org/beta/]] +  * Original source: [[http://www.slackbook.org/beta]] \\
 <!-- Authors are allowed to give credit to themselves! --> <!-- Authors are allowed to give credit to themselves! -->
-<!-- * Originally written by [[wiki:user:xxx | User X]] --> +  * Originally written by Alan Hicks, Chris Lumens, David Cantrell, Logan Johnson 
-<!-- * Contrbutions by [[wiki:user:yyy | User Y]] -->+<!-- * Contributions by [[wiki:user:yyy | User Y]] -->
  
 <!-- Please do not modify anything below, except adding new tags.--> <!-- Please do not modify anything below, except adding new tags.-->
 <!-- You must also remove the tag-word "template" below. Otherwise your page will not show up in the Table of Contents --> <!-- You must also remove the tag-word "template" below. Otherwise your page will not show up in the Table of Contents -->
 {{tag>slackbook filesystem permissions suid sgid sticky_bit chmod chown chgrp}} {{tag>slackbook filesystem permissions suid sgid sticky_bit chmod chown chgrp}}
 slackbook:filesystem_permissions ()