Roland Mainz writes:
> John.Zolnowsky at sun.com wrote:
> > system_noshell_x(const char *abs_path, uint_t flags, const char
> > *arg0,
> > ... /* const char *argn, (char *)0 */);
> >
> > system_noshell_xv(const char *abs_path, uint_t flags,
> > char *const argv[]);
>
> In general: What happens with open file descriptors when they do not
> have the |FD_CLOEXEC| flag set ?
More generally: since this new function wraps both the exec and the
fork, and since it prohibits the use of redirection, how does the user
deal with file descriptors needed in the child? How can the user
redirect (say) stdout to stderr, or stdin from /dev/null?
Other questions:
What do the functions return? I'm guessing they return 'int', but
the spec doesn't say. What values can they return? More
specifically, what happens to the return value and the 'stat_loc'
value from waitpid(3C)? (At a guess, it's the same as system(3C),
but it should be specific.)
Where are the _new_ usage cases? I've tried going through the ~211
current calls to system(3C) in Nevada, and most either pass in a
string that has nothing a user could muck with (and thus don't need
this extra bit of safety) or include redirections that would
preclude the use of this new mechanism.
For example, it looks like wilabel() is vulnerable, as it's reading
from the user, and a smart user could enter something like this as a
volume label to create havoc:
"; rm -rf /usr/bin
But that call redirects the output, so the new function doesn't seem
like a drop-in fix. And all of the CRs you cite seem to be fixed
problems. So what will use this? (Speculating on future code ... ?)
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
