Mounting Devices You don’t need the root account for those daily tasks such as surfing the net, and you won’t miss root’s authority. Most of the time, there is simply no advantage in working as root. In general: Important It is good practice to work as an ordinary (non-root) user whenever possible. Naturally, there are times when administration rights are required – for example, when adding new users, changing a forgotten password, connecting to the Internet, setting up a local area network connection, formatting a floppy disk, and so on. Red Hat Linux comes with an excellent set of tools to perform these tasks graphically – and as we’ve seen, the system asks you to enter the root password when necessary, so there’s no need to be root all the time. Here are some other tips to improve your normal user experience. Mounting Devices Thanks to technologies like USB, FireWire, and PCMCIA (or PC Card) devices, we have several removable storage media to plug into our computer. In Linux, plugging these devices in can be quite a tedious job – because each device must be mounted, and mounting a device requires administration privileges. The solution is to update /etc/fstab once and for all as root with the correct information. Once you’ve done this, normal users will be able to mount removable (or fixed) media, either graphically or via the command line. Try it Out: Mounting Devices with Normal User Accounts Let’s suppose we have a CompactFlash card containing pictures taken with a digital camera. Once inserted, Red Hat Linux supports this medium, which is considered just as if it were an ordinary hard disk. 1. If you don’t know the name of the device associated to your removable media, try to plug it in and have a look at the system logs. To do this, select Main Menu | System Tools | System Logs, or type redhat-logviewer from a terminal window. Authenticate if necessary, and then choose System Log and insert your card. You should see something like this: You can see the same lines in a root terminal by using the following command: # tail -f /var/log/messages 257
Note: If you are looking for inexpensive but high quality provider to host and run your serlvet application check Astra servlet hosting services
December 2006
Fri 22 Dec 2006
Fri 22 Dec 2006
When root Is Not Necessary drwxr-x— 2 eziodm course 4096 Jan 19 11:03 material This means that everyone belonging to the course group, and who also belongs to authors or lecturers, will be able to access the material directory. No other accounts will be able to access the directory. Now, we can create the book directory as a subdirectory of the material directory. The book directory will be Read, Write, Execute accessible by the owner and the authors group. Other users will have only Read, Execute access. This is exactly what we want, because the material folder immediately above protects the book folder from unwanted access by students, so it is safe to leave Read and Execute access for others: in our case, others can only be the lecturers group. We must not forget to activate the Set GID Bit on the folder, in order to allow our writers to cooperate nicely. So, these are the permissions for the book directory: drwxrwsr-x 2 eziodm writers 4096 Jan 19 11:04 book When root Is Not Necessary We’ve mentioned already that the protection offered by Linux when working as a normal user is a definite advantage. Certainly, working as root all the time is one of the worst habits that a novice Linux user can develop. For example, suppose you’re working as the root user, and you’re cleaning up some unwanted files in your home directory, so you want to execute the following command: # rm -rf /home/eziodm/tmp/redundant Now, consider what happens if you accidentally insert a space character, like this: # rm -rf /home /eziodm/tmp/redundant Please don’t try this out for yourself! The extra space character is almost invisible, but it completely changes the meaning of the command. The first of these commands will attempt to delete only the directory /home/eziodm/tmp/redundant and its contents. But the second command will attempt to seek out and destroy the contents of every home directory on the system! If you’re working as root, then there’s no protection – root is allowed to delete these directories, and they’ll be wiped out in an instant. You can protect yourself from accidents like this by working as a normal user. Normal users are prevented from deleting such important directories, and this is what happens when you try: $ rm -rf /home /eziodm/rmp/redundant rm: cannot remove ‘/home’: Permission denied So, the message is clear: use the root account only when it is really necessary. This generally applied policy has so far prevented viruses from spreading wildly in Linux (and Unix in general): it’s impossible for an ordinary user to infect an executable in the /bin directory, quite simply because ordinary users don’t have Write access to those files. In addition, it’s also possible to protect personal files and directories by disabling write permissions to prevent accidental deletion. 256
Note: If you are looking for inexpensive but high quality provider to host and run your serlvet application check Astra servlet hosting services
Fri 22 Dec 2006
Fifth Scenario: Restricted Write, Public Read Fifth Scenario: Restricted Write, Public Read To achieve this result, and have a directory that is shared in read-write mode among a restricted group of users and viewable read-only for the public, we only need to add Read and Execute permissions for Others: Sixth Scenario: Restricted Write, Restricted Read In this last scenario, we want the contents of the book directory to have different permissions for different groups: We want to grant Read, Write, Execute for the authors group (they need to write the contents). We want to grant Read, Execute rights to the lecturers group (they need to read the contents to prepare lectures). We don’t want any other accounts to be able to access the directory (for example, we don’t want students to peek at exercises, and solutions). The difficulty here is that we can’t set up different protections for different groups on the same directory, because only one owner and group can be specified. On the other hand, we don’t want to rely on Others for our protection scheme, because that would include students as well. Here’s a possible way to get around it. We can create a group called course, which inherits all the users from authors and lecturers. Then we proceed with creating a material directory that is Read, Write, Execute accessible by the owner (probably a lead author) and Read, Execute accessible by the course group. Other users must not have access to it. Here’s a possible example: 255
Hint: This post is supported by Gama web hosting php mysql provider
Fri 22 Dec 2006
Fourth Scenario: Restricted Write The solution is to add the Set GID Bit to the shared directory. The Set GID Bit is a special access right conceived exactly for this scenario: every file created in the directory will belong to the directory’s group, not to the user’s private group. To activate the Set GID Bit on a directory and fully benefit from it, the owner can create and initialize it with these commands: $ mkdir restricted_directory $ chgrp authors restricted_directory $ chmod ug+rwx restricted_directory $ chmod o-rwx restricted_directory $ chmod g+s restricted_directory The mkdir command creates a directory called restricted_directory, and then the chgrp command changes its group to authors. Then there are three chmod commands: The first (ug+rwx) ensures that user and group have read, write, and execute permissions The second (o-rwx) clears all permissions for others The third (g+s) activates the Set GID Bit Now we can copy files into the directory, or create files directly in it. No matter what method is used, the group will always be correctly set. This is what the directory looks like in the file manager: Note that the Text view field specifies the letter s (instead of x) in the group permissions, and in the Number view field, the Set GID Bit appears as a 2 in front of the usual three digits. 254
Hint: This post is supported by Gama web hosting php mysql provider
Thu 21 Dec 2006
Third Scenario: Restricted Read-Only The screenshot above shows
Posted by sales under redhatNo Comments
Fourth Scenario: Restricted Write The screenshot shows the permissions for a directory that belongs to the authors group. However, group members won’t have Write access to the folder. All other users (that is, users who are not members of the authors group) are completely barred. To complete our access policy on this directory, all we need to do is add the appropriate users to the authors group. It is a good idea to repeat this for each file contained in the directory. It is a tedious task with the graphical tool, but it can be quickly achieved with the command line: $ chmod -R u=rwx,g=rx,o-rwx restricted_files In this command, -R (remember that -R and -r are not the same thing!) instructs chmod to update the restricted_files directory and its entire contents, as follows: Setting the owner’s permissions to Read, Write, Execute (u=rwx) Setting group permissions to Read, Execute (g=rx) Taking away Read, Write, Execute permissions for all others (o-rwx). For additional techniques for specifying permissions, you may want to review the chmod command syntax with man chmod in a terminal. Fourth Scenario: Restricted Write As we gain confidence in the members of the authors group, we now want to give them Write access to the directory and its contents. This is not as trivial as it seems: we have to remember that each user has a different, personal, primary group. If we don’t set up the directory properly, we’ll end up with a rather messy situation: each newly created file will be assigned to the user’s primary group, not to authors. This makes file sharing a bit difficult, but still possible. 253
Hint: If you are looking for very good and affordable webspace to host and run your j2ee hosting application check Sandzak.com j2ee web hosting services
Thu 21 Dec 2006
Third Scenario: Restricted Read-Only The screenshot above shows
Posted by sales under redhatNo Comments
Third Scenario: Restricted Read-Only The screenshot above shows the permissions applied to a directory. We can tell this because the Text view starts with d (it’s drwxrwxr-x here). When applied to a directory, the Execute permission refers to the user’s authority to search files in that directory. Third Scenario: Restricted Read-Only In this scenario, we want to keep our files private, and open up the possibility of viewing the files to a limited number of users. This is where groups start to make sense: 252
Hint: If you are looking for very good and affordable webspace to host and run your j2ee hosting application check Sandzak.com j2ee web hosting services
Thu 21 Dec 2006
First Scenario: Private Files You can apply the techniques to executable programs, to control which accounts have the rights to execute certain pieces of software on your computer. First Scenario: Private Files In this scenario, a user wants to keep his or her files private. Groups are not really relevant here: it is sufficient to remove read, write, and execute permissions for others. The permissions for the group don’t really matter, since in Red Hat Linux the primary group is assigned to its primary user only. Thus, a directory with its permissions set as below guarantees privacy of its contents – that is, the directory’s content can’t be read, written, or executed by users other than the owner: Once again, it is important to note that group permissions (Read, Write, Execute) are safe because the group in question is the group called eziodm – and the only member of this group is the user called eziodm. Second Scenario: Public Read-only Files This scenario is quite simple to implement. We want to give public access to the file, and we want this public access to be read-only. Therefore, all we need to do is to ensure that the Write permission for Others is denied: 251
Quick Hint: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting plans
Thu 21 Dec 2006
Advanced Group Management # find / -nouser -o -nogroup From there, you can reassign these files to valid users or groups. To delete a group via the Red Hat User Manager GUI utility, you need to select the group, and click the Delete button. Important Beware: the group is deleted immediately, and without confirmation! Deleting Groups via the Command Line From the command line, as root, use the groupdel command followed by the group name: # groupdel authors Just like the graphical tool, groupdel will not ask for confirmation. You can check the manual page for this command via man groupdel. Users, Groups, and File System Permissions With the help of groups, it is possible to implement some very sophisticated access policies. You’ll recall from Chapter 7 that every file or directory in the file system defines access rights for three different sets of users (the owner, the group, and others) via a system of access modes that you can see when you use ls: $ls -1 drwxr-xr-x 4 eziodm eziodm 4096 Feb 12 17.40 backup_images -rw-r–r– 4 eziodm eziodm 1037238 Feb 12 17.25 picture1.bmp -rw-r–r– 4 eziodm eziodm 262314 Feb 12 17.29 picture2.bmp -rw-r–r– 4 eziodm eziodm 58398 Feb 12 17.37 picture3.bmp When it comes to user groups, the behavior of Red Hat Linux is notably different from that of many other Unix variants, including other Linux distributions. By default, every user belongs to its own private group, which is not shared with anyone else. Earlier in this chapter, we saw that whenever we create a new user account, the system tools also create a private group for that account which has the same name. Together with this user/private group scheme, Red Hat Linux also ensures that the default creation mode for files (the umask) grants write permissions to the group. Since the group (like the user account) is private, this does not compromise the security of files that are owned by the user. However, this mechanism becomes quite an advantage, when sharing files among users. In this section we’ll see six use cases regarding file protection and file sharing. You can regard them as suggestions on how to set up several protection schemes that suit normal files, directories, or executable programs: You can apply these techniques to files, to control which documents can be accessed by which accounts and groups. You can apply the techniques to directories, to control which accounts can access that directory, add files to it, or list its contents. 250
Quick Hint: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting plans
Wed 20 Dec 2006
Advanced Group Management Managing Group Membership from the Command Line From the command line and with the appropriate permissions, even ordinary users can administer groups and decide which users belong to them. This authorization comes from root, via the gpasswd command: # gpasswd -a eziodm authors Adding user eziodm to group authors # gpasswd -A eziodm authors The first command uses the -a option to ensure the eziodm account is added to the authors group. The second command uses the -A option to grant eziodm the administration rights for the authors group. Now, the eziodm user account is permitted to add new users to the authors group, like this: $ gpasswd -a markm authors Adding user markm to group authors He can also remove users from that group: $ gpasswd -d deepakt authors Removing user deepakt from group authors Revoking a User’s Permission to Manage Membership of a Group Finally, we can see what happens when root revokes administration rights for eziodm. This can be done passing an empty list to the -A option: # gpasswd -A ” authors To test that this command has indeed revoked eziodm’s right to manage the authors group, we can switch users to eziodm and use that account context to try to reinsert deepakt as a member of the authors group: # su – eziodm $ gpasswd -a deepakt authors Permission denied. As you can see, eziodm no longer has the rights to add members to the authors group. If you want to find out something more about gpasswd, you can check its manual page with man gpasswd at your shell prompt. Note When you add new members to a group, or remove members from a group, your changes are not visible until the next login, either via su – or by logging out completely and logging back in. If you use su -followed by your account name (or even newgrp followed by a group you’ve just been given access to), only commands you type in that shell (try for example id) will be affected by the new membership. Deleting Groups It is advisable to delete a group only when it doesn’t contain any members. It is possible to delete secondary groups with user accounts still associated to it. Moreover, deleting a group (just like deleting a user account) could leave “stale” files whose group no longer exists. You can run the following command periodically as root on your system, to identify these files: 249
Note: If you are looking for good and quality webspace to host and run your java application check professional java hosting services
Wed 20 Dec 2006
Deleting User Accounts usermod in a terminal) warns about this and other critical points. Note To get a list of files whose owner or group does not exist in /etc/passwd or /etc/group, you can use the following command as root: # find / -nouser -o -nogroup The find command is a very powerful and useful command. You can check other options with man find in a terminal. There’s more about it in Chapters 2 and 7. Deleting User Accounts Deleting user accounts is all too easy. In the Red Hat User Manager graphical interface, you can delete a user simply by selecting the user in the Users tab, and then clicking on the Delete button. Note Be very careful when deleting accounts via the Red Hat User Manager: there will be no confirmation! However, the user’s home directory will not be destroyed. So, in cases of accidental deletion it is possible to recover the files and create an account with the same properties of the one just deleted. From the root command line, you can run userdel. Using the command like this will erase the account called test from /etc/passwd, but the associated home directory will not be deleted: # userdel markm If you also specify the – r option, the account information, home directory, and mailbox will also be destroyed: # userdel -r markm Advanced Group Management As we’ve seen, each user account belongs to a primary group (specified in the /etc/passwd file) and can be assigned to other groups during the account creation or whenever necessary. Groups are useful when setting permissions on files or directories. We’ve already seen how to create groups and manage group membership via the Red Hat User Manager, now we’ll perform some similar tasks, and more, with the command line. The following commands will directly affect /etc/groups. Creating Groups via the Command Line You need to be logged in as root in order to create a new group from the command line. The command is groupadd, followed by the group name: # groupadd editors Optionally, you can specify the GID, like this: # groupadd -g 1973 editors For further information, you can browse the manual page by executing man groupadd from a terminal. 248
Note: If you are looking for good and quality webspace to host and run your java application check professional java hosting services