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>