Which commands (in /bin & /usr/bin) must have set user ID (for root)
Paul A. Sherman
sherm at popeye.UUCP
Tue Oct 21 02:07:16 AEST 1986
In article <735 at hropus.UUCP> jrw at hropus.UUCP (Jim Webb) writes:
>Also, /etc does not need to be 775 group sys. Make it 755.
Although /etc does not *need* to be 775 group sys, it makes ps(1) run
much faster in most cases (see explanation below). I don't know if
other standard programs make use of this situation, but I don't think
that it creates a security problem. Unless other programs that are
setgid sys have shell escapes (I don't know of any) or access to group
sys is granted indiscriminately, I think that /etc should remain mode
775, group sys, as distributed.
At least in System V, ps(1) creates a data file called /etc/ps_data
containing information from /dev, /unix, and /etc/passwd. If /etc/ps_data
is newer than those three files than it is used. Otherwise it is
recreated. On all System V systems that I've worked on, ps runs MUCH
faster when it can use an existing ps_data. This is because otherwise
it has to call nlist(3) on /unix and look through all of the entries in /dev.
Normally /etc is 775, group sys and ps is setgid to sys, so any user
of ps can create the new ps_data. If /etc is mode 755, owned by root,
ps can only successfully create a new ps_data file when it is run by
root. If things don't change much, than other users of ps will be able
to use the file that root created. However, any user changing a
password (with passwd) or login shell (with chsh) changes /etc/passwd
and makes the older /etc/ps_data unusable. Adding or removing nodes
from /dev (which admittedly happens much less frequently and requires
superuser permissions) also makes ps_data unusable since the
modification time of /dev changes.
As an aside, I have run across a couple of times that ps seemed to run
slow ALL the time, not only the first time after a change to /etc/passwd
or /dev. I found that the system had been powered off recently and
the date had to be reset. Before that happened, however, the
modification time of /dev or /unix was set to some time in the future.
Thus, ps's check for ps_data being newer than those files always failed, and
ps had to read all of its own data and recreate ps_data. The next
time, of course, the same thing happened.
--
Paul Sherman
AT&T Information Systems, Lincroft, NJ
{pegasus|ihnp4}!popeye!sherm
(201) 576-6316
More information about the Comp.unix.wizards
mailing list