Re: chfn problem with Linux

Zygo Blaxell (zblaxell@miranda.uwaterloo.ca)
Wed, 9 Aug 1995 17:18:04 -0400 (EDT)

Quoted from Olaf Kirch:
> This problem affects kill in general. The kernel allows a process
> to send a signal to another process as long as the _sending_ process's
> euid matches the signalled process's effective or real uid (cf.
> kill_prog in kernel/exit.c).
>
> I believe this should be the other way round. Quoting from the HP
> kill(2) manpage: ``The real or effective uid of the sending process
> must match the real or saved uid of the receiving process, unless the
> effective uid of the sending process is super-user.'' However, a comment
> in Lewine's POSIX book says that killing another process is also allowed
> when its ruid matches...

Ugh, let's not break this again...

Conider a script or program that terminates user accounts on a live
system. The script rewrites /etc/passwd, kills all processes owned by
the user, and deletes all files owned by the user (with appropriate
actions for crontab etc along the way). The program needs to be able to
execute 'kill -9 -1' with real uid != euid and euid == terminated user's
uid, so that the rpogram kills all of the user's processes without
leaving itself vulnerable to being killed itself by the user, or doing
something really stupid, like killing all processes owned by root and
the target user.

The real uid of the sending process should give no privileges to the
sending process except the ability to change uid's.

chfn should write to /etc/ptmp and rename it to /etc/passwd, anyway.
What if the machine crashes? This sounds more like a robustness
problem than anything to do with kill.

-- 
Zygo Blaxell, former sysadmin and current software/hardware guru for the
University of Waterloo Computer Science Club; current sysadmin for miranda.
uwaterloo.ca and ezmail.com.  10th place team, ACM Intl Finals Programming 
Contest 1994.  Will administer Unix (esp. Linux, maybe Solaris) for food.