|
|
LINUX ACCESS MODES AND STICKY BITS EXAMPLES• Sticky Bits - Examples • Setting suid And sgid • Directories And sgid • sgid Sticky Bit Example • sticky/setgid/setuid Table • The Sticky Bit • setuid On Executables • Another Example With setgid • RemovingSticky Bits Sticky Bits - Examples
Access modes
If suid or sgid bits are set then:
Lowercase “s” => the file is executable UPPERCASE “S” => the file is NOT executable Setting suid And sgidIn the octal number format, suid has the value 4 in the first (high order) digit, while sgid has the value 2.Directories And sgidA directory has the sgid mode enabled means that any files or directories created within it will inherit the group id of the directory. This can be very useful for directory that is used by a group of people working on say the same project...sgid Sticky Bit ExampleBelow shows how user “greg” could set up a directory that all users of the development group could use, along with an example of how user “gretchen” could create a file in the directory. As created, the file gretchen.txt allows groups members to write to the file.Create user “greg” and user “gretchen”: useradd -m greg useradd -m gretchen => Set their passwords to “123” passwd greg passwd gretchen cd /home/greg/ mkdir Our_Big_Project_Together Setup a group called “developer” and make these new users members of this group:  The first digit in the above mode number is used to set setuid, setgid, or the sticky bit. Each remaing digit set permission for the owner, group, and world is as follows: sticky/setgid/setuid Table
sticky/setgid/setuid
where: 1 = sticky bit 2 = setgid (set group id) 4 = setuid (set user id) Login as User “greg”, create a new directory in User greg’s home directory called “Our_Project_Together” mkdir Our_Project_Together   Now set the group name of the directory to “developer”:  Now set the “setgid” (Set Group ID) bit. We need in place of the “x” in the group to be an “s” (LOWER CASE “s” NOT UPPER CASE “S”). Therefore to generate say rwx rwx r-x would be merely 775. Based on this we just have to change the group “x” component via the setgid (set group id). Now when Gretchen (who is a member of the group called “developer”) enters this /home/greg/Our_Project_Together/ directory, when she creates a file, that file inherits the group name of the directory (i.e. “developer”) – see in orange below in the Terminal output:
 However, as usual, if gretchen creates a file in her own home directory then the Owner and Group name of the file is both “gretchen”:  Any member of the development group can now currently create files in user greg's Our_Project_Together directory. Currently, the file gretchen.txt allows members of the group “developer” to write to her file Gretchen.txt because the group permissions are set to rw- (read and write but not execute). That is to say, the Owner (gretchen) can rw- (Read,write) the file, the Group can rw- (Read,write) and the Others cant do anything --- .  To prevent this so that other members of group “developer” can’t write to her file Gretchen.txt but can read it, do the following (rw-r-- ---):
chmod 640 gretchen.txt  Now add the group “developer” to User “fred”:  Now User “fred” is a member of the group called “developer”:  User “fred” can’t write to this Gretchen.txt file, but he can read it:  Note: I can easily give User “fred” the ability to write to this file via rw- rw- --- i.e.
chmod 660 gretchen.txt  To set the setuid (set user id) so that anyone can execute the script (as if they were the root user) via ./script.sh nano script.sh
#!/bin/bash
echo “Hi” exit 0 rwx r-x r-x => 755 Therefore, from the table above, we place the 4 in front chmod 4755 script.sh  Linux ignores the setuid bit on all interpreted executables (i.e. executables starting with a #! line). The Sticky BitWe have just demonstrated that anyone with the write permission to a directory can delete files in it. This might be acceptable for the above situation whereby a group of people working on a project together need this facility, however this situation might not be a such a great idea for say globally shared file space such as the /tmp directory.The sticky bit "t" solves this problem. It is represented symbolically by t and numerically as an Octal 1.
sticky/setgid/setuid
where: 1 = sticky bit = t 2 = setgid (set group id) = s or S 4 = setuid (set user id) = s or S The "t" is displayed in a long directory listing where the executable "x" would normally be seen for the Other user. This has the same meaning as suid and sgid in terms of the upper and lower case nomenclature. If set for a directory, it permits only the owning user or the superuser (root) to delete or unlink a file. Below shows how user “greg” could set the sticky bit on his Our_Projects_Together directory. rwx rws r-t For rwx rwx r-x we would need 775, for rwx rws r-x (i.e. “s” merely replaces an “x” in the group column for setgid) this is 2775 as shown above (where the “2” sets the setgid). i.e. rwx rws r-x Now to also have the sticky bit “t” we add the left most column numbers i.e. we need the “2” for the setgid and we also need a “1” for the sticky bit i.e. 2+1 = 3 chmod 3775 Our_Projects_Together
 As explained above, the sticky bit being set here means that If set for a directory, it permits only the owning user or the superuser (root) to delete or unlink a file:  So, even though User “fred” is a member of the group “developer” and that group has rw- privalages here for Gretchen.txt, because the Our_Projects_Together directory’s sticky bit is set, User “fred” can’t delete this Gretchen.txt file. User “fred” can still write to the file as normal here:  Although User “gretchen” can remove it too:  User “greg” can delete it too:  NOTE: Also, you can see that the root directory /tmp has this bit is set by default: ls –l /  NOTE: The setuid permission set on a directory is ignored on UNIX and Linux systems. setuid On ExecutablesWhen setuid is set on an executable file, normal users who have permission to execute this file get their privileges elevated to that of the user who owns the file (often the root user).Note that many Linux operating systems ignore setuid when applied to executable shell scripts. This is due to obvious security issues. Key points w.r.t setuid: • The setuid permission set on a directory is ignored on UNIX and Linux systems • Many operating systems ignore the setuid attribute when applied to executable shell scripts. Another Example With setgidI want a directory whereby only members of group “developer” can view inside it. I also want this directory to force new files and subdirectories created within it to inherit its group ID rather than the primary group ID of the user who created the file:d wrx wrx ---
   e.g. Now User “Jon” who isn’t a member of Group “developer” CAN’T see inside this directory. If user “gretchen” creates a file inside this New_Our_Project_Together directory, then like above we get:  i.e. gretchen’s new file “anotherfilebygretchen.txt” inherits the group ID of the directory New_Our_Project_Together (i.e. it inherits the group “developer)” here. RemovingSticky BitsIf for example you have the following directory called Testy with these sticky bit permissions set: Note that the following WILL NOT remove it: sudo chmod 777 Testy/ This however will remove it: sudo chmod g-s Testy/ Terminal Output:  The reason for this is that you can set or clear the bits with symbolic modes such as say u+s and g-s, and you can set (but not clear) the bits with a numeric mode. |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
Linux Examples - Comments |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
