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?

  • make a copy and chmod it or something.
    – mikeserv
    Jul 3, 2015 at 1:25

2 Answers 2


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).


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

If you have strace, and it is not setuid to root, then

strace -e '!all' program_name [argument(s)]

should work.  strace(1) says (under BUGS):

Programs that use the setuid bit do not have effective user ID privileges while being traced.

because it would be a security problem if a non-privileged user could trace a setuid program (because tracing lets you examine and modify the process's memory).  But also, in a special section called SETUID INSTALLATION, it hedges the above a little:

If strace is installed setuid to root, then ... setuid and setgid programs will be executed and traced with the correct effective privileges.  ... only users trusted with full root privileges should be allowed to do these things, ...

So, if strace is installed setuid to root, then the above trick won't work.  But this shouldn't generally be the case.  And, even if it is, you can work around it by making a private, non-SUID copy of strace.  (I'm thinking that, even if /bin/strace gets automatically updated, you shouldn't need to update your private copy.)

As for the command, -e tells strace what events to trace.  -e all would mean "trace all events" (which is the default), so -e '!all' means trace none.1  This should cause strace effectively to do nothing but stand by and watch as your program (the X program) runs.  If it produces unwanted output anyway, redirect output to /dev/null.  (This assumes that you don't need to see the console output from the X server.)
1 You will probably need to quote !all to prevent the shell from treating the ! as a history reference.

You must log in to answer this question.

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