execve() vs system() for chrooted filesystems in dbcommands.c
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
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.
Windows does have execve(), though it's named _execve(). Not sure if
that means it has slightly different behaviour than on Unix. See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/h
tml/_crt__execve.2c_._wexecve.asp.
But looking at the code you will notice that win32 already does not use
system() - copydir() is available to do it internally. Haven't looked at
the details, but perhaps this can just be used straight off on Unix as
well.
From what I can tell, rm is also handled in the rmtree() function, and
not by system(), since version 1.138 of dbcommands.c.
//Magnus
Import Notes
Resolved by subject fallback
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