Re: [PATCH] Fix system() behaviour when parameter is NULL

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> "access() is a potential security hole and should never be used."
> Actually, the statement is wrong...  Rather, it needs a few more
> qualifiers.  One of the original purposes of access() was to let
> setuid() programs check if the real uid had certain privileges on the
> file.  That doesn't work properly because of race condition attacks.

Well...strictly speaking, it works, but opens up a classic test-vs-use
race if you then proceed to count on the result to mean that it's safe
to use the pathname you tested.  (Except for cases where all the
directories leading to the object are unwritable to all attackers
inside the threat model, which is the case rarely enough that the
possibility can usually be ignored.)

This is rather more complicated than someone needing the manpage is
likely to grok; the warning that's there is a workable approximation
for the people who need warning.

> However, if you're not looking at that issue, it's a perfectly fine
> system call.

Yes.  However, is it the right one here?  If system()'s caller is
set-id, I'm not convinced it will give the answer we want if the ruid
and euid have different access rights on _PATH_BSHELL.

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B