Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ihnp4!popeye!sherm
From: sherm@popeye.UUCP (Paul A. Sherman)
Newsgroups: net.unix-wizards
Subject: Re: Which commands (in /bin & /usr/bin) must have set user ID (for root)
Message-ID: <32@popeye.UUCP>
Date: Mon, 20-Oct-86 12:07:16 EDT
Article-I.D.: popeye.32
Posted: Mon Oct 20 12:07:16 1986
Date-Received: Tue, 21-Oct-86 23:40:10 EDT
References: <115@tijc02.UUCP> <735@hropus.UUCP>
Reply-To: sherm@popeye.UUCP (62545456-Paul A. Sherman;LZ 3E-303;6316)
Organization: AT&T-IS Labs, Lincroft, NJ
Lines: 45

In article <735@hropus.UUCP> jrw@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