Thanks for the comments. Nicolas Williams wrote on 10/28/08 15:05: > On Tue, Oct 28, 2008 at 02:44:53PM -0700, Sumanth Naropanth wrote: >> This project aims to provide a new public interface called the >> 'exec_system()'. This function will be implemented to provide the same > > What's the rationale for this name? Are there similar functions in > other Unix or Unix-like operating systems? >
The intention is to provide a very system()-like interface that doesn't execute using the shell. The new function uses execve() (via posix_spawn()) to do the actual execution and hence 'exec_system()'. I don't see any standard library functions in other Unix-like operating systems using the name exec_system(). I intend this to be Solaris-specific. >> ease of use as the system(3C), by defining a single (const char *) >> argument. The implementation will be a wrapper around the >> posix_spawn(3C)/waitpid(3C) functions. This interface will provide >> greater security in comparison with the system() function by avoiding >> shell invocation. Quoted arguments will be supported by using a new >> macro called 'ES_QUOTE', which will be defined as: >> >> #define ES_QUOTE '\377%s\377' >> >> The special character '\377' is chosen since it lies outside the >> printable character set. This quoting mechanism will make it harder for > > Is that true for *every* character set and encoding scheme that we > support or might support? It's true for US-ASCII and for UTF-8, for > example, but not for ISO8859-1, for example. > I agree that it's not impossible to supply '\377' as an input when some encoding schemes may allow for it. Using '\377' makes it much harder (but not completely impossible) to trick the argument parsing than using single/double quotes. > So this is likely a terrible choice of quote character. Perhaps the > only safe quote character would be NUL, and then you'd need to use NUL > NUL as the terminator (or something). > NUL was actually considered as the delimiter instead of '\377' but I'm not sure if that would be the right thing either. None of the string.h functions will be valid on the argument string and it may confuse the parser when NUL is passed as a terminator. > Moreover, why even have a quote character? Make this function take a > variable number of arguments, with the last being NULL, and be done. > Sounds like a good idea, but that pulls it away from a simple (const char *) interface. I'll give this more thought. Thanks! >> arbitrarily quoted user inputs to cause execution of unintended code. >> But for whitespaces, no other shell meta-characters will be supported by >> the exec_system() function. >> >> When used inside a setuid program, the exec_system() function will drop >> privileges to those of the real user while executing the file/command. > > Maybe the user ID (real or effective) to use should be an argument, as > well as whether to drop privs. > This feature mimics the behavior of system(3C) when it's used inside setuid program. Again, it's a trade-off between providing an extended functionality (to allow execution as effective user) versus keeping the interface simple and less daunting. >> The exec_system() implementation will extend the signal handling model >> of system(3C) and will set SIGCHLD to be blocked for the calling thread, > > Why not use forkx() to avoid SIGCHLD issues altogether? > Using posix_spawn()/waitpid() allows me to pass the return value of the execve() call back to the parent process when exec fails. I don't suppose forkx()/exec() will allow for that (apart from just causing the child to exit(127))? Regards, Sumanth
