Re: loading kext from a daemon program
Re: loading kext from a daemon program
- Subject: Re: loading kext from a daemon program
- From: Michael Smith <email@hidden>
- Date: Sat, 6 May 2006 02:51:49 -0700
On May 5, 2006, at 2:23 PM, David Gatwood wrote:
On May 5, 2006, at 12:02 PM, Michael Smith wrote:
On May 5, 2006, at 2:44 AM, Quinn wrote:
At 13:33 -0700 4/5/06, Terry Lambert wrote:
Alternately, the fork()/exec()/wait() is encapsulated for you as
well, if you use the system() library routine.
Although I'm always leery of using "system" from a privileged
program, like a daemon. This is mostly relevant when the program
is setuid (where a potentially malicious caller can set up a
specific environment to cause problems), but I take the overly
cautious route and avoid it in any privileged program.
I'm with Quinn here. System(3) belongs with gets(3) in that pile of
tools that you never, ever use.
I disagree. If you use full paths and properly vet the arguments
for shell escapes
(or if the paths and arguments are not extracted from user input in
such a way that
embedded shell escapes would be possible), the system(3) call is
not substantially
less safe than fork and exec.
This is rather like saying that if you declaw, de-fang and hogtie a
tiger, it's a perfectly safe housepet.
Then later some other poor soul discovers that tigers are heavy when
it rolls over and crushes them.
For that matter, the security difference between system(3) and popen
(3) is zero, and
the alternative to that involves some really, really ugly code
(dup2 over top of
STDERR_FILENO or whatever). That's just not something that most
people will
want to do if they can help it. :-)
popen(3) belongs in the same pile. And if socketpair(2) is too hard
for you, you should not be playing this game.
Thus, I don't think it makes sense to suggest avoiding these at all
costs. You should,
however, be careful when using them. Always use absolute paths.
(This is important
for some variants of exec(3) as well.) Avoid passing user input in
as part of the
argument list. If it is necessary to pass user input in as an
argument, make sure
it doesn't contain anything but letters, numbers, and spaces unless
you -know-
how to properly quote shell commands. And so on.
... don't forget to write your code in such a fashion that it will
never, ever be reused, because you can't enforce these constraints
when it is.
... don't ever use this code when performance matters, because the
shell is typically a pig to start even when all it is going to do is
the fork/exec that you should have done yourself.
... don't get too cocky about "absolute paths". / is relative (think
chroot(2)).
Ask yourself... why are the spawn family of interfaces so popular, if
system(3) is so great?
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden