Java Reference
In-Depth Information
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.
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
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
Nonroot-Installed Software
4. Some folks pronounce this “ess-you doo,” and some “pseudo.” Whatever floats your boat.
