1

I'm carrying out a one-off configuration operation which requires a remote client to communicate with a remote server. The client runs Apache, which runs a configure binary, which fetches various scripts from the server with curl. The returned scripts must be run by root.

On the client configure is C++ code, and the binary is setuid root (no lectures please, unless you've got a better idea):

$ ll /var/www1/cgi-bin/configure 
-rwsr-xr-x 1 root root 76160 Jul 13 19:20 /var/www1/cgi-bin/configure*

The configure code creates a randomly-named directory in /tmp with mkdtemp:

# ls -ld /tmp/vs_MYSosq
drwx------ 2 root www-data 4096 Jul 13 20:29 /tmp/vs_MYSosq
# ll /tmp/vs_MYSosq
total 8
drwx------  2 root www-data 4096 Jul 13 20:29 ./
drwxrwxrwt 25 root root     4096 Jul 13 20:29 ../

The code then execs curl, which retrieves the scripts, but then fails to write them to this directory (it exits with code 23).

Any idea why curl can't write to this directory? Is this fixable or do I have to move out of /tmp (which is preferred because it's a ramdisk)? It's presumably a sticky-bit issue, but I can't see how, since the directory is empty and curl isn't attempting to over-write anything.

Improve this question
3
  • your script really should do the least possible as root. Especially, downloading shouldn't be done as privileged user. Personally, I'd fix that first: download what you need to download with as few privileges as possible, and only after that is done, call the setuid binary which does, and only does, the things you really need root privileges for. Honestly, a setuid CGI program just sounds scary to me; it'd be a reason for to reconsider my architecture! I'm a bit surprised your system let's you do that at all: pretty sure SELinux would stop me, would I try to run a setuid CGI from apache.
    – Marcus Müller
    Commented Jul 13 at 19:57
  • 1
    Shells throw setuid away. So when you call curl the shell that calls curl throws setuid away and curl runs unprivileged. See Allow setuid on shell scripts and setuid not working
    – Chris Davies
    Commented Jul 14 at 7:02
  • 1
    @ChrisDavies - thanks - the setuid(0) fixed it. I've marked the question as a dupe.
    – QF0
    Commented Jul 14 at 15:25

1 Answer 1

Reset to default
0

I don't have a simple & secure solution to do it the way you've described it.

However, creating and using another directory that is not /tmp can be a viable solution and may help you avoid permission issues associated with the default configuration and security policies of the /tmp directory.

For instance, you can create a new directory under /var or another suitable location.

sudo mkdir /var/tmpdir
sudo chown root:www-data /var/tmpdir
sudo chmod 770 /var/tmpdir

Then modify your configure binary to use this new directory instead of /tmp.

If SELinux is enforcing policies that restrict writing to the new directory, you might need to adjust the SELinux context:

sudo chcon -R -t httpd_sys_script_rw_t /var/tmpdir

Make sure that any temporary files or directories created in this new location are properly cleaned up after use. You can use a cron job or include cleanup code within your configure script.

Thank you!

Improve this answer

Not the answer you're looking for? Browse other questions tagged .