Which commands (in /bin & /usr/bin) must have set user ID (for root)

[Jim Webb]

> I currently have VAX 11/785s running AT&T UNIX V Release 2 Version 2.0.
> I am wondering which commands in /bin /and /usr/bin (owned by root, group is
> sys)  must have the set user ID, or set group ID on execution in order
> to work correctly.

-rwsr-xr-x   1 root     sys         9784 Apr  3  1986 df

df needs to be able to read the superblock of the filesystem(s) to see how
many blocks and inodes are free.  Unfortunately, the standard version allows
it to open ANY device; it should restrict non-super-users to those devices
found in /etc/mnttab (mounted filesystems)

-rwsr-xr-x   1 root     sys         8360 Nov  5  1983 mkdir

only root can mknod directories, as the . and .. entries are put in
somewhat manually by the command.  If anyone could make directories,
I guess somewhere along the line someone in their application would
not do it correctly and minor mayhem would ensue.

-rwsr-xr-x   1 root     bin        18936 Nov  5  1983 newgrp

needs suid so that one can change his/her group id.

-rwsr-sr-x   1 root     sys        19068 Nov  5  1983 passwd

obvious.

-rwsr-xr-x   1 root     sys         8796 Nov  5  1983 rmdir

like mkdir, only root can unlink directories.

-rwsr-xr-x   1 root     sys        19484 Nov  5  1983 su

obvious.

-rwsr-xr-x   1 root     sys        47197 Oct 20  1985 at

at needs to talk to cron in a very specific manner.
It should be noted that this is why the files in
/usr/spool/cron/atjobs are setuid and setgid to the submitter,
for cron (yes, cron) stats the file and does a setuid and setgid
on the owner and group of the file.  However, some pond scum (:-) could
chgrp and chown the files to root and have them then run as root.
SO, at makes sure the setuid and setgid bits are set, as they are
cleared on chowns.

-rwsr-xr-x   1 root     sys        25093 Nov  5  1983 crontab

crontab tells the cron daemon to create individual crontabs.  It does
this by writing on /usr/lib/cron/FIFO which had better be 700 owned
by root.  Otherwise, a user could manipulate cron quite freely.
You should at this point make /usr/spool owned by uucp and modes
755.  As distributed, /usr/spool is 777, so a user could 
mv /usr/spool/cron to /usr/spool/cron/.cron and replicate the
directory structure, obviously adding a nicety to root's crontab.
Although this would not be noticed until the system is rebooted
or cron re-run, it is usually worth the wait...

---s--x--x   1 root     sys        41980 Oct 16  1985 ct

ct needs to be suid root so that when it calls /etc/getty, getty can
write in /etc/utmp and /etc/wtmp to log the login.  It also needs to
run as root so that login will work, as by default, login is NOT suid.
You could setuid root login and then people could successfully login
again via "exec login"

-rwsr-xr-x   2 root     bin        37232 Nov  6  1983 sh

just kidding...

-rwsr-xr-x   1 root     sys        22380 Nov  5  1983 shl

shl needs it so that it can set/reset  the owners of the sxt devices
as well as twiddle some other things.

> I hesitate to change the permissions without knowing why the commands
> had the set user id on execution in the first place.  Or in other
> words, I have changed the permissions on a FEW commands and they stopped
> working. 

snicker snicker

Some more comments on suid root programs.  Do yourself a favor and make the
following change, it will make a lot of hackers (like myself) not like your
machine too much, but....

	chmod 777 /usr/preserve
	chmod u-s /usr/lib/ex*preserve

By no means does ex*preserve need to be setuid root.  It did when it was
on berkeley, as chown was/is restricted to root there, but not under SV.
I guess you could make a group "vi" and setgid it to vi, and make
/usr/preserve 775, group vi if you wanted to be a bit more secure.

Also, /etc does not need to be 775 group sys.  Make it 755.
-- 
Jim Webb             "Out of phase--get help"          ...!ihnp4!hropus!jrw