Re: execve() vs system() for chrooted filesystems in dbcommands.c

Tom F said:
> Hi,
>
> I'm working on running postgresql in a chrooted filesystem.
>
> /src/backend/commands/dbcommands.c makes use of system(3): as far as I
> can see, this is only used to execute rm(1) and cp(1). I'd like to
> avoid placing /bin/sh in the root of the filesystem (which system()
> requires).
>
> I see four options:
>
> 1. Replace calls to system() with calls to execve(). This is feasible,
> as no complex commands are passed to the shell: just execution of
> programs with arguments.
> 2. Put /bin/sh in the filesystem. This is exactly what I am trying to
> avoid, if only because every piece of shellcode ends in "/bin/sh"
> 3. Make /bin/sh a simple wrapper which is only capable of executing one
> program. This is silly and unneccessary.
> 4. Move the functionality of cp(1) and rm(1) into the postgresql source
> tree. This is unneccessary extra work.
>
> 1 seems to be the cleanest option to me, and also removes the
> (marginal) overhead of launching a shell. So, I shall be doing this for
> my own use, unless I've overlooked a reason not to.
>
> My question: would my patch be accepted if I submit it?
>
> The only argument against it, that I'm aware of, is that system() is
> ANSI, while execve() is POSIX: i.e. portability... does windows have
> execve()? That could be done the way the current preprocessor
> conditionals yield rmdir instead of rm.
>
> Thanks,
>
> - Tom

system() is not the only call that uses the shell - popen() does too. It is
used extensively in initdb, for example, and would probably not be simple to
replace (especially on Windows) - simplicity was the reason it was used in
the first place.

cheers

andrew