execve() vs system() for chrooted filesystems in dbcommands.c - Mailing list pgsql-hackers

From Tom F
Subject execve() vs system() for chrooted filesystems in dbcommands.c
Date
Msg-id 20040920051255.GB4958@void.printf.net
Whole thread Raw
Responses Re: execve() vs system() for chrooted filesystems in dbcommands.c
List pgsql-hackers
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:
justexecution 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
endsin "/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

pgsql-hackers by date:

Previous
From: David Wheeler
Date:
Subject: Re: libpq and prepared statements progress for 8.0
Next
From: Greg Stark
Date:
Subject: Re: libpq and prepared statements progress for 8.0