Date: Wed, 1 Dec 1999 00:39:02 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>, Bill Fumerola <billf@chc-chimes.com> Cc: Kris Kennaway <kris@hub.freebsd.org>, Matthew Dillon <dillon@apollo.backplane.com>, Dan Moschuk <dan@FreeBSD.ORG>, arch@FreeBSD.ORG, audit@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h Message-ID: <v04210100b46a5eebcf42@[128.113.24.47]> In-Reply-To: <91218.943989222@zippy.cdrom.com> References: <91218.943989222@zippy.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 11:13 AM -0800 11/30/99, Jordan K. Hubbard wrote:
> > Depending on a behavior that isn't defined anywhere and doesn't
> > always work falls in my definition of "negative clue".
>
>You're too newly-minted an admin to have an informed opinion about
>this, I hate to say. People who've been doing Unix since the 70's
>have different definitions of "defined" since anything you use for
>over 10 years becomes "defined" whether it's written down anywhere
>or not, and there are thousands of examples of this around.
Hmm. I think you're putting the emphasis on the wrong part of
his sentence. I read it as:
Writing something which *depends* on this behavior is a
bad idea, because this behavior does not always occur.
Ie, it is *already* true that you can't "depend" on it.
And since the behavior isn't written down anywhere as
part of any standard, someone who depends on this can't
even complain when the behavior does not happen.
At the same time, I think there's a difference between finding
something "useful" (as I remember the original comment), and
"*depending* on that behavior". Something which is true 95% of
the time can be "mighty useful" at times, even if I wouldn't
want write anything which "depends" on that behavior.
Just out of curiosity, is there some way we can provide the
"useful" part even if the PID's are randomly assigned? Ie,
what exactly *is* useful about sequential PID's? My guess
is just that you want a history of which processes started
in which order (including processes which may not be around
any longer, or which have been reparented). Perhaps we
could have some other mechanism for that? Is there any
other legit benefit to having consecutive PID's? I'm just
wondering, because that's the only benefit I've gotten from
consecutive PID's.
What I'm thinking is maybe just a wrapping buffer that keeps
the last <x> PID's which were assigned, and the PPID of the
process that started each of those PID's. I imagine it'd
be nice to also include process-creation timestamps, but that
might chew up memory too fast. Would that provide the desired
benefit, while still avoiding the security issues?
[I'm sending this to both -arch and -audit, but I imagine the
discussion should continue on just -arch...]
---
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or drosih@rpi.edu
Rensselaer Polytechnic Institute
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-audit" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v04210100b46a5eebcf42>