chapman@sco.COM (Brian Chapman) (12/01/87)
In article <1261@saturn.ucsc.edu> haynes@ucscc.UCSC.EDU (Jim Haynes) writes:
< Incidentally, there's a security hole connected with setpgrp()
< in that the system doesn't check whether the pgrp number you
< proffer is already in use by somebody else. So with a little
< cleverness you can attach to the pgrp of someone else's process
< and proceed to kill it.
<
< haynes@ucscc.ucsc.edu
< haynes@ucscc.bitnet
< ..ucbvax!ucscc!haynes
Humm, are you talking about BSD or SYS V?
I have SYS V manuals and kernel source right here handy
and there is nothing obviously wrong.
SYSTEM V setpgrp() takes no arguments and sets the process
group number equal to the pid. Elsewhere in the kernel the
definition of a process group leader is the process where
p->p_pid == p->p_pgrp.
So, you cannot get in someone elses process group as long as
the group leader is alive. OK... what if the leader is
dead (the user nohuped some processes and logged out).
I looked at exit() and right in the loop where the
children are given to proc 1 there is a check for
if(p->p_pid == q->p_pgrp) q->p_pgrp = 0;
where p is the process dieing and q is the pointer
that is looping through the proc table.
So, you cannot get into a process group as long as the
process group leader is alive and if the group leader
dies then the process group is dissolved.
Well, I looked at kill just for good measure. The
arguments of 0 "kill my process group" and the
arguments < 0 for killing some process group == abs(arg)
all check that the uid/ruid of the user is either
0 or equal to the p_uid/p_suid of the process.
So even if I missed something in the process group stuff
it doesn't look like kill() would do anything for you.
All this would lead me to believe that you are talking
about BSD. But then I _know_ you administer BSD systems!
-- Brian Chapman (ucsc alum)ron@topaz.rutgers.edu.UUCP (12/02/87)
What process groups do in system V and BSD are completely different. The bug only applies to the BSD tty driver. -Ron
lwv@n8emr.UUCP (Larry W. Virden) (12/05/87)
As the originator of this article, I would like to relate one antedote as to why it came up. We are doing some development on a particular vendor's system who claims system v compatibility. So, we used setpgrp() as documented in the SVID - they DID claim that they were SVID system call and library compatible of course. But the vendor in question has as default a BSD environment and by adding particular info to one's environment, one states to the various components of the system that one wants system 5 or bsd ( notice how hard i struggled to keep that statement from telling you who this is? I havent checked yet to see things are the same on the OTHER TWO VENDOR PRODUCTS out there - but they appear to be!) Anyways, the code was doing a setpgrp() and was getting the strange behavior. I looked in all three vendor docs and it appears that they all use the BSD setpgrp(). Isnt setpgrp() a SVID function? how can 3 major forces in the Unix world (you would CERTAINLY recognize two of the vendors - they only have 3 letters in the primary means of referencing them - the other is a little less known but also has its own usenet group in comp.sys) claim SVID compatibility and then not provide that? Just curious on other's opinions. -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 cbosgd!n8emr!lwv (UUCP) cbosgd!n8emr!lwv@ucbvax.Berkeley.EDU (BITNET) We haven't inherited the world from our parents, but borrowed it from our children.