QProcess won't launch GUI apps after executing setreuid

Josef Lintz

I have a "bootstrapper" program which initially is run as root.
Inside the "bootstrapper" I have a function which calls setregid, and setreuid to change the "caller" to a different (non-root) user.

The problem is after I call the function I can no longer run graphical apps.
This is the error I'm getting
"
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-customer'
No protocol specified
qt.qpa.screen: QXcbConnection: Could not connect to display :0
Could not connect to any X display.
"

Let me just be clear, this only happens after changing the effective/real user.
If I don't change the user, QProcess works fine.

JonB

@Josef-Lintz
Well you could always start from man xhost :) I can already see:

[+]name

The given name (the plus sign is optional) is added to the list allowed to connect to the X server. The name can be a host name or a user name.

-name

The given name is removed from the list of allowed to connect to the server.

So xhost +thatuser would make sense.

JonB

@Josef-Lintz
Indeed, this does not surprise me!

X is only set up so that the logged-in user can use it, not some other user. I don't know what you can do about that/whether it can ever be made to work this way.

First confirm that as you (not setreuid) it can "connect to display :0", so we know the display is set up right.

Then I would guess this is not a Qt issue. Google for stuff about "how to run X11 application setuid". or something like that. E.g. there is https://serverfault.com/questions/51005/how-to-use-xauth-to-run-graphical-application-via-other-user-on-linux, but not sure that is your case. It's about authority, not sure that's what your " Could not connect to display :0" is about.

I believe you are saying that once you have changed effective user you then cannot use QProcess to launch UI apps? If you restore to the original user before launching the process does that make it work? But I suppose you will say that is not what you want.

Josef Lintz

@JonB

First confirm that as you (not setreuid) it can "connect to display :0", so we know the display is set up right.

Are you referring to running echo $DISPLAY? If so, then on all users including root I get ":0"

If you restore to the original user before launching the process does that make it work? But I suppose you will say that is not what you want.

I can't really do that after changing to a non-privileged user

I will check out the other stuff you provided, and will see

Josef Lintz

@JonB I have news, your reply did lead in the right direction.
I discovered the command xhost +, which to my (very limited) understanding, disables some authority of X, which allows any user to run GUI apps, even if they are not currently logged in.

This is a solution, but I would like to know the consequences of using xhost +, and if there's an option to only allow certain user's to run GUI apps.

JonB

@Josef-Lintz
Well you could always start from man xhost :) I can already see:

[+]name

The given name (the plus sign is optional) is added to the list allowed to connect to the X server. The name can be a host name or a user name.

-name

The given name is removed from the list of allowed to connect to the server.

So xhost +thatuser would make sense.

Josef Lintz

@JonB

So xhost +thatuser would make sense.

Yup, that's exactly what I did.

Thank you so much for your help.

ChrisW67

I discovered the command xhost +, which to my (very limited) understanding, disables some authority of X,

As @JonB said, "it's about authority". xhost + disables the default, rudimentary access control mechanism in X11 and will allow anyone to use your X server. In the scenario you describe this means the user you execute your child X11 program as can display output on the root X11 display. It also mean any user on the machine, or any other machine, can display stuff on your root display. This strikes me as undesirable.

xhost +si:localuser:username would be better. For example:

# default state
chrisw@newton:~$ sudo -u testuser xeyes
No protocol specified
Error: Can't open display: :0
# wide open
chrisw@newton:~$ xhost +
access control disabled, clients can connect from any host
chrisw@newton:~$ sudo -u testuser xeyes  
# ... and it displays
^C
# 
chrisw@newton:~$ xhost -
access control enabled, only authorized clients can connect
chrisw@newton:~$ xhost +si:localuser:testuser
localuser:testuser being added to access control list
chrisw@newton:~$ sudo -u testuser xeyes  
# ... and it displays
^C

A tighter approach would be to take the the X11 cookie from your running X server and merge it into the X11 cookies known by the other user. You can do this with xauth nextract ... and xauth nmerge ... or by copying your .Xauthority to a temporary file (readable by the other user) and launching the child process with the XAUTHORITY environment variable set to the temporary file patch. This will take a bit of experimentation.