20.3. Be an Enabler, or "Let's Be Codependent!" People often give inadequate consideration to the issues of management of software systems. This is especially true of Java systems, which are, by their nature, cross-platform. We have the luxury of dealing only with Linux systems here, so we can make some practical suggestions most books ignore. Up to this point, we have largely been considering a situation where the Java developer is working on an individual workstation where he or she has root access. Now that we are talking about application servers, we are dealing with systems where, as the software progresses from development through rounds of testing to production, we will want to limit the people who are able to change certain elements of the system. Often, the "quick and dirty" strategy is to share out the root password to a number of users. This is a serious security risk, even when all parties are trusted. Why? Because root isn't a person. When someone logs in as root, we do not know who that person is. We only know that it is someone who knows the root password. In some businesses, this is an unacceptable ambiguity in audit. A common alternative is to restrict root login to the console only, and to require the use of the su ("set user") command to promote an already logged-in user to root status. This provides a link back to the individual, so actions can be traced to single person. That improves auditability. This strategy is better, but since root is an all-or-nothing proposition, it is a fairly blunt instrument. Once someone can su to root, that someone can do anything. That's a lot of power to give to someone who just needs to be able to install WAR files. Yet another strategy is to set up the sudo system.[4] Using sudo, you can specify what people can execute which commands as root, and where they may do it from. In other words, you might let user alice start and stop the Web server and mount and unmount filesystems when she is logged in to a local machine, but only to start the Web server when she is logged in on a machine outside your network. Check out the manpage for sudo to learn more. Even this isn't the best solution for the present issue. [4] Some folks pronounce this "ess-you doo," and some "pseudo." Whatever floats your boat.
The best solution is not to require root power at all if you can avoid it. Remember that permissions on files in Linux are assigned to users, groups, and others. Most people do not think about the middle tier, groups. But groups are the best way to give control over parts of the filesystem to a collection of users without requiring them to share an account and password. 20.3.1. Nonroot-Installed Software The problem with all of the power-sharing strategies we outlined earlier is that once the user escalates to root, there is no way to limit what he or she can do (well, sudo lets you limit it, but a mistake can be fatalconsider what happens if you let them run a program that lets them escape to a shell). So, for example, if you want to let the Web services group install and maintain JBoss, but you don't want them to mess with any standard software on the system, then create a separate place for nonsystem software. Two common places for such software on Linux systems are /opt and /usr/local. We tend to use /usr/local mainly because this is the default path on an awful lot of software that uses autoconf to handle cross-platform compilation (it is used by the majority of Free Software programs, but exceptions include what are arguably the four most widely used Free Software packages: the Linux kernel, the Apache Web server, the Perl language, and XFree86). So we are going to install JBoss under /usr/local and we are going to give a number of users the power to install and manage software in /usr/local. You will need to be root to carry out this procedure. Here are the stepsbut don't worry, we'll pad them out with a lot of ponderous explanation: 1. | Create the group.
Groups are defined in the file /etc/group. Each line in that file defines a group. Each line is of the form:
GroupName:x:GroupID:GroupMembers
GroupName is the name of the group. It is the group name that shows up in long form ls output. The second field is for the group's password. If we may confess, we don't know if this feature works anymore. You used to be able to specify a group password, but this defeats the whole purpose of not sharing passwords. Sharing passwords is a security risk. Don't do it. The third field is the group ID number. Remember that files have owning users and owning groups. These are both stored as numbers. User numbers are known as uids and group numbers as gids. These numbers should be unique. If you reuse a number for more than one group, the effect could be indeterminate, since it would depend on how a given program was written. Don't reuse numbers. The final column is a comma-delimited list of user names. Those named users are said to belong to the group. We'll talk some more about what that means as we go on.
Imagine that user names bob, ted, carol, and alice are part of carl and michael's Web development team and each has an account on the box on which we intend to install JBoss.
So, we create a group entry in the /etc/group file:
local:x:100:carl,michael,bob,carol,ted,alice
If Bob later leaves to join the custodial staff, simply remove his name from the group and he loses his access.
Tip The user's default group is specified in the /etc/passwd file. Here's a sample: mschwarz:x:500:500:Michael Schwarz:/home/mschwarz:/bin/bash
The fields of this are: username:passwd:uid:gid:userinfo:homedir:loginprog
where: username is the login name of the user. passwd is the user's encrypted password. Or rather it used to be. Now, this is usually x and the encrypted password is stored in the /etc/shadow file. This is because /etc/passwd must be world-readable. The shadow file is not. This prevents someone reading the encrypted passwords to do an offline dictionary attack. uid is the numeric user ID associated with this username. gid is the numeric group ID of this user's default group. Look for this number in /etc/group to find the name of the default group. userinfo is additional information about this user. Sometimes called the gecos field for obscure historical reasons,[5] this field usually stores the user's real name and possibly other information like office location and phone number. [5] See http://www.hyperdictionary.com/dictionary/GCOS if you are dying to know why.
homedir is the user's home directory. loginprog is the name of the program that will be executed when the user logs in. This is usually a shell, but it may be any program.
Note There are two strategies that Linux distributions follow for assigning a default group to a new user. One is to put all users into a group called staff or some such. This is widely considered a security risk since it often leads to making files accidentally readable or writable by all users on the system. The more common method is to create a group for each user when the user is created. Tip If you get in the habit of creating groups, you might want to assign the numbers systematically: 500599 groups for programs, 600699 groups for program installation, 700799 groups for company departments to allow them to control their own Web content, and so on. | 2. | Change group ownership of /usr/local.
Odds are, /usr/local already exists on your system. It may even have several programs installed in it. You must give the group ownership over everything in /usr/local and below. The chgrp command changes the group owner of files, and the -R argument says to do so recursively:
# cd /usr/local # chgrp -R local .
At this point, everything in /usr/local and below is group-owned by the local group.
| 3. | Set group permissions on /usr/local.
Basically, you want the group to be able to read and write everything in /usr/local. To do this, you need to change the permissions on all the files with the chmod. As with chgrp, this command takes a -R argument that recursively walks the directory tree. We need to give everyone in the group read and write permission on all the files:
# chmod -R g+rw .
Note We are assuming you are carrying out these steps in sequence and thus your current working directory is still /usr/local. | 4. | Set directory permissions on /usr/local.
You want slightly different permissions on directories. First, you want the group to have execute permission on directories. This allows each member of the group to make each directory his or her current working directory. See Eric Raymond's Unix and Internet Fundamentals[6] for a good basic introduction to file permissions on UNIX.
[6] http://en.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/disk-layout.html#permissions
Also, on Linux systems, when a user creates a file, that file is, by default, group-owned by the user's primary group,[7] which is not what we want here. We want files created by a user in this directory to be group-owned by the local group. To do this, we have to set the setgid bit on all the directories in /usr/local and below. When a user creates a file in a directory that has the setgid bit set, that file will be group-owned by the group-owner of the directory if the user is a member of that group. If the user is not, it will be group-owned by the user's default group as usual. So we need to set execute and setgid permissions on all the directories in /usr/local and below:
[7] Which is the group ID specified for the user in the /etc/passwd file.
# find /usr/local -type d -exec chmod g+xs {} \; -print /usr/local /usr/local/share /usr/local/share/bochs /usr/local/share/bochs/keymaps /usr/local/share/bochs/keymaps/CVS /usr/local/share/doc ... ... etc.
With this setup, members of the local group can manage files and programs in /usr/local and below as they wish. They have full power over the files and they need nothing but their own login credentials to do it. The root password can remain private.
|
20.3.2. Finer Grained Control This pattern can be repeated. We can give ownership of different branches under /usr/local to other groups to allow control to be doled out in small sets. |
