Running setuid binary temporarily without setuid

executablepermissionssetuidxorg

Currently setting up xpra, which wants to run an X instance as non-root using the dummy driver, but the system Xorg binary is SUID. Since the system auto-updates, I would prefer not making and maintaining a non-SUID copy of the binary. I'm also trying to avoid using a hack like copy-execute-delete, e.g. in the tmp directory (would prefer to make it a clean one-liner, which I instinctively believe should be possible, though there may be some subtle security hole this capability would open). Symlinks would be acceptable, though AFAIK they don't provide permission bit masking capabilities.

My current best solution is a nosuid bind mount on the bin directory, which seems to do the trick, but as above I'd still prefer a solution that doesn't leave crunk in my system tree/fstab (e.g. some magic environment variable that disables suid the same way a nosuid mount does, or some commandline execute jutsu that bypasses the suid mechanism).

Any thoughts?

Best Answer

If X is dynamically linked, you could call the dynamic linker like:

/lib/ld.so /path/to/X

(adapt ld.so to your system (like /lib/ld-linux.so.2).

Example:

$ /lib64/ld-linux-x86-64.so.2 /bin/ping localhost
ping: icmp open socket: Operation not permitted

Related Solutions

Bash Error – Cannot Execute Binary File

The message cannot execute binary file has nothing to do with terminals (I wonder what led you to think that — and I recommend avoiding making such assumptions in a question, as they tend to drown your actual problem in a mess of red herrings). In fact, it's bash's way of expressing ENOEXEC (more commonly expressed as exec format error.

First, make sure you didn't accidentally try to run this executable as a script. If you wrote . ./executable, this tells bash to execute ./executable in the same environment as the calling script (as opposed to a separate process). That can't be done if the file is not a script.

Otherwise, this message means that ./executable is not in a format that the kernel recognizes. I don't have any definite guess as to what is happening though. If you can run the script on that same machine by invoking it in a different way, it can't just be a corrupt file or a file for the wrong architecture (it might be that, but there's more to it). I wonder if there could be a difference in the way the target boots (perhaps a race condition).

Here's a list of additional data that may help:

Output of file …/executable on server B.
Some information about the target, such as the output of uname -a if it's unix-like.
Check that the target sees the same file contents each time: run cksum ./executable or md5sum ./executable or whatever method you have on the target just before yet-another-bash-script invokes ./executable. Check that the results are the same in the Hudson invocation, in your successful manual invocation and on server B.
Add set -x at the top of yet-another-bash-script (just below the #!/bin/bash line). This will produce a trace of everything the script does. Compare the traces and report any difference or oddity.
Describe how the target is booting when you run the scripts manually and when Hudson is involved. It could be that the target is booted differently and some loadable module that provides the support for the format of ./executable doesn't get loaded (or is not loaded yet) in the Hudson invocations. You might want to use set -x in other scripts to help you there, and inspect the boot logs from the target.

Linux – Make all files under a directory read-only without changing permissions

This answer works on Debian (tested on lenny and squeeze). After investigation, it seems to work only thanks to a Debian patch; users of other distributions such as Ubuntu may be out of luck.

You can use mount --bind. Mount the “real” filesystem under a directory that's not publicly accessible. Make a read-only bind mount that's more widely accessible. Make a read-write bind mount for the part you want to expose with read-write access.

mkdir /media/hidden /media/hidden/sdz99
chmod 700 /media/hidden
mount /dev/sdz99 /media/hidden/sdz99
mount -o bind,ro /media/hidden/sdz99/world-readable /media/world-readable
mount -o bind /media/hidden/sdz99/world-writable /media/world-writable

In your use case, I think you can do:

mkdir /var/smb/hidden
mv /var/smb/snapshot /var/smb/hidden
mkdir /var/smb/snapshot
chmod 700 /var/smb/hidden
chmod 755 /var/smb/hidden/snapshot
mount -o bind,ro /var/smb/hidden/snapshot /var/smb/hidden/snapshot

I.e. put the real snapshot directory under a restricted directory, but give snapshot read permissions for everyone. It won't be directly accessible because its parent has restricted access. Bind-mount it read-only in an accessible location, so that everyone can read it through that path.

(Read-only bind mounts only became possible several years after bind mounts were introduced, so you might remember a time when they didn't work. I don't know offhand since when they work, but they already worked in Debian lenny (i.e. now oldstable).)

Best Answer

Related Solutions

Bash Error – Cannot Execute Binary File

Linux – Make all files under a directory read-only without changing permissions

Related Question