PDA

View Full Version : QProcess Shell Command (Linux) Elevate Privileges?



m3rlin
5th April 2013, 21:41
@Moderator - I am aware that this is a borderline QT Programming issue, I hope you allow this post.

Hi,

I am running into a weird problem with QProcess and I would like your advice on how to solve this.
I have build a program installer. ( for several reasons I do not want to distribute my program using a package manager)

The installer needs to save icon files(.png) in the /usr/share/icons/hicolor/<icon-size>/apps/ folder and a desktop-entry file in /usr/share/applications. (for both folders, superuser privileges are mandatory on the main distro's)
I am developing the installer with QT 4.8 on (K)Ubuntu KDE-Desktop with kdesudo installed. I am not using kdesudo/gksudo, and neighter ssh-askpass function since Fedora, OpenSuse, Arch and CentOS don't support these functions as a standard. I therefore choose to use QProcess and the sudo command (re: security holes I am using QCA Libs and AES-128 for encryption/decryption of the superuser password).

On execution in a linux terminal I am asked for the sudo password (my test account is in the sudoers file, else I would get an error). The result is very disappointing: a KDESUDO related bug telling me that the Gui is owned by User 1000 (me) and not by Usr 0 (superuser). I found out that this has been a reported bug and it was confirmed.

I am now looking into an alternative to elevate privileges using Qt Process and the sudo command. The net hasn't been very helpful. So if you have successfully elevated permissions using sudo and Qt Process, I'd love to hear about how you did this?

Thanks.

wysota
5th April 2013, 22:38
My suggestion would be to just run the whole installer using sudo (you can check euid from within the installer to see if you have effective root privileges or not). Since you'll have to elevate privileges sooner or later, it doesn't really matter if you do it before launching the installer or afterwards.

m3rlin
5th April 2013, 23:34
Well that is indeed the whole problem... I am lauching the installer (process A). At the end of collecting information I use QProcess to start process (B) the worker who is actually doing all the tasks. I do this for several internal security reasons. Would process (B) - when executed by the initially elevated process (A) carry over elevated privileges? I use QProcess Start not execute...
Thx for your quick r

wysota
5th April 2013, 23:39
I think it should inherit euid from the parent process.

anda_skoa
6th April 2013, 17:07
My suggestion would be to just run the whole installer using sudo (you can check euid from within the installer to see if you have effective root privileges or not).

Actually it might be even better to check if, e.g. write access, is allowed on the target directory.
The user might not be superuser or not running the process with superuser priviledges but might still have write permissons due to being a member of the group owning the directory.

For example on my system /usr/local and /opt belong to group "staff" and my main user is in group "staff" so I can always install into /usr/local or /opt, so there is no need to give elevated permissions to any installer.
If an installer checks for root priviledges I take this as a sign that its author has very little clue about file system permissions and therefore it should defnitely not be allowed to execute with elevated permissions.

Cheers,
_

m3rlin
6th April 2013, 20:53
Actually it might be even better to check if, e.g. write access, is allowed on the target directory.
The user might not be superuser or not running the process with superuser priviledges but might still have write permissons due to being a member of the group owning the directory.
Cheers,
_

Actually I do that for the selected installation directory, and it works fine. On the command prompt if I start the installer with sudo ./setup it will install the icons and desktop.entry file as wanted, so that seems at the moment to be the only way... I also set file permissions afterwards (for all installed files) to be of owner user instead of owner root. But that still doesn't satisfy my need for incidental elevation of user rights. I'd prefer the setup fase A (collection of information) to be with normal user rights and ONLY Face B - the worker, (and ONLY for saving the icons and desktop.entry file) to have elevated rights. This would keep the security hole tight and also be considered proper use. I am reading the policyKit while typing but that seems to be a lil over the top....

wysota
6th April 2013, 22:32
If an installer checks for root priviledges I take this as a sign that its author has very little clue about file system permissions and therefore it should defnitely not be allowed to execute with elevated permissions.

Maybe I was not clear enough -- what I meant was that if the installer can't work without additional privileges, then run it with sudo (it doesn't even have to be sudo root). If I ever suggested that the installer should force to be run with superuser privileges then that's not what I really meant -- it can check and warn the user but if he knows better, the installer can continue.

m3rlin
6th April 2013, 23:45
Wysota and Anda,

I actually missed that line of anda_skoa. But I also seem to miss his point, so maybe this will clear it a bit more: Linux has become more "user" friendly, and more people tend to give it a try. Them users are no wiz-people, and many come from a Windows, or Mac environment - which basically means that they will spend a lot of money for guys like us to fix things that happen under the 'hood' - cuz they have no clue, and they don't want to know. I have seen folks return to WIndows because they feel that tagging .debs into executables, or using any package manager, or apt-get install commands is just a little too much for them.

Clicking on setup from their GUI is what they recognize, and they expect a certain behavior from the setup.
I intend to satisfy most of those expectations, but cannot set symlinks in $HOME/Desktop/ pointing to /usr/share/icons/<icon-size>/apps directory without elevating permissions. I can also not save a desktop.entry file in /usr/shar/applications/ without ditto elevation. Once files have been installed as superuser, I reset file permissions to local user with standard priviliges (don't forget my target audience is not Linux savvy - and doesn't know that files saved as superuser will have READ/WRITE/EXEC as superuser - which basically renders my program useless because they can't exec it with their credentials. I think that and 26 years of IT experience counts for knowing about file system permissions.

I agree - until I have found a better way, with Wysota: there is no alternative available (covering most Distro's) without creating a security hole and a lot of programming overhead. So asking my target audience (non-linux-geeks) to elevate their privileges and protecting that user from installing files in places other than to which he himself has READ/WRITE permission is momentarily the best I can do. Unless you can suggest a better way...?

wysota
7th April 2013, 00:12
Have a script that will call kdesudo, gtksudo or whateverelsesudo and tell it to launch your new installer. If your user is experienced, he can launch the installer directly using options of his own choosing. Other lusers can just doubleclick the script icon, type in the password and sit back while the installer does the rest.

m3rlin
7th April 2013, 06:44
Hmmm I thought of that too, the main problem with this approach is that Fedora and CentOs have no sudo installed (OpenSuse, Ubuntu and (K)Ubuntu do) as a standard so I need to use su - in general. For Debian alike only KDE/Gnome support kdesudo and gksudo, but not all of them. On Ubuntu for example su - won't work at all, since that needs the root password and root is a disabled account. So I'd need to use sudo su- or the GUI gksudo/kdesudo. Either way I must see into preventing the Home directory from being set to root (with su- or sudo) and I need to copy the .Xauthority to a temporary place else the work environment becomes root (as it does now). I am running out of scope with making a Linux/Win Installer and was wondering if there are any alternatives? As for now it looks like making an RPM/DEB file is the only way or suffer a blow when using QProcess.

ChrisW67
7th April 2013, 07:45
but cannot set symlinks in $HOME/Desktop/ pointing to /usr/share/icons/<icon-size>/apps directory without elevating permissions
If the user's home directory is not writeable to the user then it seems you have larger problems to deal with.

Is the point of this entire exercise to allow random user A to install the software on the system for use by all users or just themselves?

If this is meant to be a user-only install then there should be no need for elevated privileges. Install in a user-writeable area, put a *.desktop file into .local/share/applications and you should be done.

If the software is to be installed system wide then (IMHO) far and away the best packaging option is the native one for the relevant system. Then the user, who is familiar with their own system, can use the system's familiar tools to install and uninstall your software. Of course, this imposes a work load on you if you want to do this for half a dozen different packaging schemes. There's no way around requiring elevated rights to install system-wide and no way to accommodate every variation on a theme.

m3rlin
7th April 2013, 09:01
@ChrisW67, no the problem is with the system wide install, by random user X, installing my program for anyone.

I am considering (I might not have a choice) not installing my program as a system wide application, to avoid all the mess as you mentioned. What remains on the table is the HOW TO elevate user privileges on Linux Distro's in a proper manner using a GUI with QProcess. It has degraded from must implement to the "I MUST KNOW HOW" feeling. So I cross-posted my question on a Linux Forum where they suggested I'd write a make script to handle elevations for the worker process (B) - leaving the GUI out of it. But that defies the purpose of my installer. I will find out how to do this eventually. In the mean time I thank you all for supporting this topic.

anda_skoa
7th April 2013, 12:05
Clicking on setup from their GUI is what they recognize, and they expect a certain behavior from the setup.

Sure, nothing wrong with that. However, most installers on Windows do not elevate their priviledges themselves either, they usually also require that the user has permissions to install to a certain directory.



I intend to satisfy most of those expectations, but cannot set symlinks in $HOME/Desktop/ pointing to /usr/share/icons/<icon-size>/apps directory without elevating permissions.

As ChrisW67 said, if you can't write into the user's home directory then there is something seriously screwed with the user's system setup.



I can also not save a desktop.entry file in /usr/shar/applications/ without ditto elevation.

Of course, I would even consider that path "off-limits" to any 3rd party software installer. /usr is the path managed by the system itself. Like C:\Windows (or whatever it is on current versions).

For that reason I actually prefer 3rd party software to come with an installer (instead of trying to have a package), because it not only allows users to install non-system wide, it allows users who are trusted by the sysadmin to install system wide in a way (e.g. /opt, /usr/local) that does not interfere with the system itself.



Once files have been installed as superuser, I reset file permissions to local user with standard priviliges (don't forget my target audience is not Linux savvy - and doesn't know that files saved as superuser will have READ/WRITE/EXEC as superuser - which basically renders my program useless because they can't exec it with their credentials.
Are you sure? Usually executables installed by root are owned by user root, group root (unless the mount settings override that) but are executable for all.



So asking my target audience (non-linux-geeks) to elevate their privileges and protecting that user from installing files in places other than to which he himself has READ/WRITE permission is momentarily the best I can do. Unless you can suggest a better way...?

Which is the same as on Windows, no? You have to right-click and "run as administrator" to be able to install into a global locations.

Cheers,
_

wysota
7th April 2013, 12:38
Are you sure? Usually executables installed by root are owned by user root, group root (unless the mount settings override that) but are executable for all.
Yeah, executables are executed with permissions of the user executing it, not the one owning the executable unless the executable has the setuid bit set.