Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Jul 1998 19:48:44 -0400
From:      "Allen Smith" <easmith@beatrice.rutgers.edu>
To:        Stefan Eggers <seggers@semyam.dinoco.de>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: Best means of telling if a proc is still around?
Message-ID:  <9807131948.ZM9979@beatrice.rutgers.edu>
In-Reply-To: Stefan Eggers <seggers@semyam.dinoco.de>        "Re: Best means of telling if a proc is still around?" (Jul 13, 10:07am)
References:  <199807130807.KAA04341@semyam.dinoco.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 13, 10:07am, Stefan Eggers (possibly) wrote:
> > Hi. What's the best fast means of telling if a reference to a proc
> > structure is still valid? I'm needing this for the work on privileges
> > that I'm doing. (Specifically, there are circumstances where an action
> > initiated by a process that then exits may be a privileged one, and
> > may not get to the point of checking the privileges before the exit
> > takes place.)
> 
> Use at_exit(9) to know when it exits.  If it is important to you an
> at_exec(9) might be needed, too.  The latter does not exist, yet.

Sorry; I wasn't clear enough. The situation I'm worried about is the
following:

	A. process does system call or other action requiring a
	   privilege check (for something other than uid 0, which is
	   already checked for in, for example, socreate). The system
	   call returns to avoid blocking, say, a rt process.
	B. process exits
	C. system call or other action gets to the point of the
	   privilege check
	D. privilege check attempts to access privilege flags,
	   associated with the process, that aren't there
	E. all hell breaks loose because it's accessing a now-nonsense
	   memory location

I don't want to do the checking at A, since a lot of times that would
mean doing a full-scale interpretation of what the system call is
doing at the time of the call, which is likely to be a duplication of
the stuff happening later. I suppose I could do an at_exit call at
each such system call, but that's going to result in a definite slowdown.

Yeah, I know, I'm being a perfectionist - this combination isn't
_that_ likely to happen (indeed, I'm not sure if there are any
circumstances in which it _can_ happen currently) - but I'd prefer to
fix the potential problem now before it bites somebody trying to add
capabilities to the system who won't be as familiar with the workings
of this as I will be (since I'm writing it).

	-Allen

-- 
Allen Smith				easmith@beatrice.rutgers.edu
	

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9807131948.ZM9979>