Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!snorkelwacker!bu.edu!buengc!bph
From: bph@buengc.BU.EDU (Blair P. Houghton)
Newsgroups: comp.unix.questions
Subject: Re: Killing the correct process
Message-ID: <5414@buengc.BU.EDU>
Date: 24 Feb 90 23:41:28 GMT
References: <22332@adm.BRL.MIL> <5312@star.cs.vu.nl> <1212@root44.co.uk> <5382@buengc.BU.EDU> <5615@star.cs.vu.nl> <5405@buengc.BU.EDU> <5636@star.cs.vu.nl> <5410@buengc.BU.EDU> <5650@star.cs.vu.nl>
Reply-To: bph@buengc.bu.edu (Blair P. Houghton)
Followup-To: comp.unix.questions
Organization: Boston Univ. Col. of Eng.
Lines: 62

In article <5650@star.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes:
>In article <5410@buengc.BU.EDU>,
>	bph@buengc.BU.EDU (Blair P. Houghton) writes:
>)...
>)Sending a kill -HUP to a login-shell in the console window
>)of a uVAX workstation Running Ultrix clobbers all of a
>)login's processes and cycles the X server.
>
>Ever heard of `signal(SIGHUP, SIG_IGN)'?

I use HUP because it gives the honest processes a chance to
use `signal(SIGHUP, somethinguseful)'.

If you want, you can try this:

	stream_type fp;
	char line[WAYBIG];

	/* Already got user's uid via whatever means. */
	fp = popen("/bin/ps axl","r");
	while ( fgets(line,sizeof(line),fp) != (char *)NULL )
	    if ( uid == parse_for_uid(line) )
		kill( parse_for_pid(line), SIGKILL );
	pclose(fp);

SIG_IGN that!

(BTW, most of the time in that loop is spent waiting for
the `ps axl' to get aroung to its first line of output,
so it's more economical than one would think, at first.)

Of course, this is overkill when the only people I plan to
force the schedule on are almost uniformly without any
knowledge of unix, much less esoterica like execl's.  I'll
know well anyone who knows what a SIG_IGN is, and I'll
trust them not to bust my stuff, or I won't let them log in
at all.

It's obvious that unless you're trying to implement it as a
convenience rather than a security measure you're going to
have to rewrite the kernel, or add a killsession() call,
or getcherself a Real Operating System (hah!)...

>Furthermore: race conditions!

Which never elaborate themselves...

>)It's still a crap-shoot, but it's a crap-shoot with
>)probability of failure that has an *upper* bound of
>)1/30,000.  That is one in 30,000 times when the same
>)person has logged out and logged back in on the same
>)workstation on the same day.  Such a situation is not
>)too common in a big lab with tons of students and lots
>)of workstations.  [...]
>
>I was talking of events with much higher probability.

Wot?  You can assign a PID to your own process?  I'd like
to see that...

				--Blair
				  "Blair -v"