![]() |
![]() |
![]() |
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
![]() |
![]() |
To access the contents, click the chapter and section titles.
Complete Idiot's Guide to Linux
Setuid, Setgid, and Sticky BitsIn addition to the permission bits described in the section Permission by the Numbers: 4, 2, 1, and 0, UNIX provides three other bits that are used for other purposes. The setuid bit sets the user id of the running program to the user id of the owner of the program. This way, the program can run with permissions that the user of the program doesnt necessarily have. The program, when running effectively, has the same user id as the owner of the file. Similarly, the setgid bit runs a program with the group id of the group that owns the program. This assignment allows programs to access files and processes that the user running the program would not normally have. The setgid bit under Linux also has a special use. When set on a directory, it sets the group ownership of files added to the directory. This way, even though the default group for a particular user is different than that of the group, it is assigned to the project directoryensuring that files created there will be accessible to members of the group. The sticky bit is used in conjunction with directories to protect files the directory contains, although it was originally designed for a different purpose. When set, it only allows the owner of the directory, the owner of the file, or the superuser to delete files that the directory contains. The sticky bits presence is how directories like /tmp that are shared by many users have a little more privacy than they would have using the standard permission settings. The setuid, setgid, and sticky bits have the values of 4000, 2000, and 1000, respectively, and are set using the chmod command. To use them, just add the file mode to the values (or combinations you want) to them. To grant or deny setuid/setgid or sticky permissions using symbolic mode, use s for setuid and setgid and t for sticky. For example, if a directory has a mode of 777 (which means RWX permissions for all users), you can set the sticky bit by changing its mode to 1777. To set the setgid, you would change the mode of the same directory to 2777. Using symbols, to set the suid bit on a file, you would use u+s. To set the setgid bit, use g+s. To set the sticky bit, use a+t. The Default File Mode: umaskAll files are created with a default mode, depending on the file type (a regular file or a directory). Wouldnt it be cool if you could somehow define the settings that you want when you create files? Well, you can! This process involves using the umask command. The numbers you provide to the umask command are similar to the ones for the modes, except that they have had their bits inverted. This means they are not as straightforward to work with. Dont ask me why there isnt a less strange way of setting these bits; thats just the way it is. To view your current umask, type umask at the shell: [alberto@digital alberto]$ umask 022 To make it easy for you, Im providing a table with reasonable umask values that you can set (see Table 16.3). If you dont see the values you need in the table, you can set those permissions on the fly by using the chmod command. (Thats what I do when the umask command requires too much thought.)
Now all you need to do is type the umask command followed by the value you want to set. From then on all files you create during the current session will have those properties. So what umask should you use? It depends on your need to share files with others. Your default umask will depend on whether your administrator added a User Private Group (see Group Ownership and User Private Groups). If your account has a UPG, the default umask is 002; otherwise it is 022. Group Ownership and User Private GroupsSometimes youll want to collaborate with different users on a project. This situation probably means that you will want to edit files others create, and they will want to edit files you create. To make this collaboration work while protecting the work from other users, you need to work with groups. Typically, a group is created for a project, and users are added to the group. Files for the group collaboration will be put in a neutral directory in the system. This directory will allow read, write, and execution privileges to members of the group. To ensure that files created in the directory belong to the group, the setgid bit mentioned in the section Setuid, Setgid, and Sticky Bits is set on directory. (Creating groups is discussed in Chapter 18, Users, Groups, and Passwords.) The only problem with this approach is that the permission of files will be set according to the users umask and, in turn, will depend on whether the user has a User Private Group (UPG). When UPGs are used, instead of users belonging to the generic group users, Linux creates a UPG for the user when the account is added. The user is (and should be) the only member of his or her own group. This exclusiveness allows the user to have an umask of 002 without compromising the security of any personal files. By default, a umask of 002 allows full control of the file to the owner and the group associated with the file. In the case of the UPG, the group linked to the file is also the owner, so things are safe. If the UPG mechanism is not used, members of the group will have to be systematic about the umask they use when creating project files. Given human nature, the result is that a series of files will be editable by the owner only, requiring the owner to do a chmod on the file to allow other members of the group to modify the files. The UPG mechanism provides a solution to this problemand for this reason it is very cool.
|
![]() |
Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement. |