App runs slower and looks odd when using 'runuser' command

Josef Lintz

(Sorry for the late reply, I was off work)
That's actually the very first thing I tried a while ago, before even going the route of using scripts.

The bootstraper was at first a simple C++ program which ran as root and used setreuid to change to the appropriate user (Here, for example).

But unfortunately it had the exact same problems as I've described here.

SGaist

Strange...

Can you explain your use case ?

Is it something started as the root user ?
Is it something that is started automatically at startup ?

Josef Lintz

@SGaist
I'm working on a computer system which has two logins

One login is the "administrator", i.e. "primary user".
The 2nd login is reserved for customer use.

All (relevant) binaries are located inside the administrator's ~/binaries/[program_name] directory/ies (Don't ask me why, I'm not the one who built it like that) because we don't want the customer to access the company/program configuration files.

The customer doesn't have permissions to read/write anything inside the administrator's home directory.

Is it something started as the root user ?

To run the program which initializes the system as the customer, I either have to run the program using sudo by allowing the customer to (only) run the program as root without password (Which we do now, and that's a problem).
Or (As the customer) use a "bootstrapper" script/program as I've described above, to run the program as the system-admin (primary user).

Is it something that is started automatically at startup ?

It might have to run at startup, but if the underlying issue is taken care of, then I can add the program to startup-programs.

Also, one more note which I forgot to mention.
We're using a somewhat older version of Ubuntu,16.04.

SGaist

Hum...

I don't know if it would be something doable but would a dbus service help in this case ?

Your client application would only have to request the service to do what is reserved to the administrator user and it could be run as any other user without requiring any access to the "private area" of the administrator account nor the use of sudo.

Paul Colby

I'm curious about the "looks odd" bit... if you could show use screenshots of both, that might give some clues? I appreciate that the app in question is probably sensitive, so even just one of the basic Qt sample apps might help.

Also, since you are already using sudo, is it any better if you skip the intermediate runuser command, like:

sudo -u *privileged*-user '/path/to/RunAppScript.sh'

Paul.

Josef Lintz

@SGaist
I'll have to look into it. I've never heard of that term

Josef Lintz

@Paul-Colby
I'll see what I can do about that image, it'll have to wait for tomorrow, unfortunately.

I'll try that command, when I'm at work again

Josef Lintz

@Paul-Colby
So I've got those images. Hopefully they convey what I mean when I say when it looks odd.

Couple of things though, I tried changing the font.
When I run the program with runuser (or any of its derivatives), I noticed that the fonts are somewhat similar but different in a way I don't understand.

This how one of the programs is expected to look under normal circumstances, i.e. when the "privileged-user" runs it (Assuming that the privileged-user is currently the one who is logged in to the computer).

This is how the program actually looks like when we run it as root, or using runuser, sudo -u, etc..

It's as if when running it not as the user currently logged-in, QT doesn't respect the style applied for fonts and Icons.

Also, about that command you suggested, it still has the same problems.
But I'll probably use it, because it is simpler.

JonB

@Josef-Lintz
Just chipping in, may be helpful, maybe not!

I'm a little surprised that anything works running a UI program as a user other that one who actually logged into the X desktop, but apparently it does. But not surprisingly is picking up something different from somewhere.

I have not heard of/used runuser. @Paul-Colby has recommended sudo -u ..., but you say that is still not right. I would have tried sudo -E -u ..., does that make any difference?

Josef Lintz

@JonB
It seems that when setting export XDG_RUNTIME_DIR=/run/user/1000 In the script, adding the unprivileged-user to the xhost doesn't make much difference, other than that, in general, I make sure that the user unprivileged-user is included in xhost "whitelist".
⠀

However, sudo -E -u ..., worked perfectly, it seems like -E was the key.
I was sure that export XDG_RUNTIME_DIR=/run/user/1000 also sets the environment, but I was wrong.
I cannot thank you enough, this has been a problem for months now.

For future readers, the complete steps to allow an unprivileged-user to execute a program from folder which he doesn't have permissions to read/execute are as follows:

First, add the unprivileged-user to the sudoers file by running sudo visudo, Then add the following lines:

# This allows 'unprivileged-user' to *only* run 'app' as 'privileged-user' without having to type-in a password.
unprivileged-user computer=(privileged-user) NOPASSWD:SETENV: /bin/bash -c cd path/to/secure/folder; ./app

Then, create a simple script which has the following command

sudo -E -u privileged-user bash -c 'cd path/to/secure/folder; ./app

(Of course, modify as needed)

JonB

@Josef-Lintz said in App runs slower and looks odd when using 'runuser' command:

However, sudo -E -u ..., worked perfectly, it seems like it -E was the key.

That is what I would have used. -E tells sudo to inherit the environment of the caller; without it a new environment for the sudo user is created. That will not be the same as the environment which is set up if that user actually logged into X desktop, like the original user did. Now, there are doubtless items in the environment of the caller related to being logged onto the X desktop which are needed in the context of the sudo shell/command, hence probably required to make a UI program work. If you really want to look at all the differences, do an env | sort from each of sudo with and without the -E and compare.

Josef Lintz

@JonB
I see, so when I run sudo -E -u privileged-user bash -c 'cd path/to/secure/folder; ./app as the unprivileged-user, the environment is set to that of the user who executed the command?
But the program is run as the 'privileged-user '? Have I understood correctly?

Also, while experimenting I observed something odd.
This problem only affects QT, we have a GUI app which uses wxWidgets/GTK and it doesn't to be bothered by which environment its using.

What exactly in QT is so "sensitive" to the "changes" in environment?

JonB

@Josef-Lintz said in App runs slower and looks odd when using 'runuser' command:

Have I understood correctly?

Yes. Without -E it creates a brand new environment for the root user not based on the user who is logged into the X windows. With -E it carries the current user's environment over to the root shell.

The problem is likely that something in the original logged on environment is required to work correctly with desktop/X but is wrong or not appearing without -E. Like I said, if you want to try to understand do an env | sort once from sudo -s ... and once from sudo -E -s .... Whatever environment variables are different are potential culprits.

Since this is environment variables there could be differences about what does/does not matter between "wxWidgets/GTK" versus Qt, so stuff works OK for one but not the other.