QProcess Shell Command (Linux) Elevate Privileges?

[wysota]

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]

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]

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]

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]

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]

@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]

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]

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.