Hi,

I am running into a weird problem with Qt QProcess and I would like your advice on how to solve this. I have build a linux 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, and CentOS don't support these functions as a standard. I therefore choose to use Qt QProcess and the sudo command (re: security holes I am using QCA Libs and AES-128 for encryption/decryption of the superuser password). -- just in case you wanna slaughter me over this.

On execution in a linux terminal I am asked for the sudo password (my test account is in the sudoers file. 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 somewhere confirmed -- not sure about this.

I am now looking into an alternative to elevate privileges using a shell and 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.

Most likely the bug is that the script (being owned by someone other than root) is attempting to be run by the root (thus opening a vulnerability - specifically, a trojan attack).

fedora ,CentOS/RHEL/SL use the root id of 500
with the first non root user as 501
opensuse uses 1000


fedora and cent also do not have sudo turned on by default .Opensuse dose


i would just use " su - "

but fro fedora,cent,and opensuse why not just make a rpm

I need to look into a different approach for launching elevation of privileges. su - would be an option on Fedora and CentOS, but not on Ubuntu (sudo su -). And the main reason for explicitely not making an RPM/DEB/TAR is that my target audience is not Linux Savvy at all. They expect a setup with a next and a back button

The architecture of the installer is the following: Process A (pId A) collects information. pId A launches another process pId B (inheriting from pId A) to do all the work. pId B needs privileges to save icons and a desktop.entry file in the appropriate files (folders). So I am looking at elevating pId B and trying to avoid to set HOME= to ~root, and asking myself how to copy .Xauthority to a different directory, etc... it might be easier to start the whole setup as superuser with a crowd unaware of what the security issues are, and how Linux works under the hood, but that kinda defies security policies and proper programming standards.

rewrite a Makefile to do the installing
make is very versatile , i even use it in image processing to run the commands in a rather long and complex process

or just create a install.sh file
have the person run it as root on their system

That would be a nice solution indeed. I am under some time pressure to perform, so I have come to the conclusion that I will not let user X install a system-wide application for anyone, but rather have that person install an application for him/herself only, therefore I don't need to elevate privileges. I will try a make script and see how QProcess responds to it -- to satisfy the "I must know how this works" feeling.

Thannk you (all) for support.

Unfortunately, such an installer opens a trojan attack via a race condition between the "collects information", and process B. If the data collection is subverted, then the privileged process will do things you don't want.

And you can't just copy the .Xauthority (well, you can, but where it exists varies from system to system, and you can't always just copy it. MAC labeling can prevent it).

Next, you can't avoid the HOME issue - unless you fully elevate priviges to root (su -), you don't necessarily get the privileges needed to install.

Fedora 17/18/19 do use 1000 for the base UID/GID by default now, though like all the other distributions, this is up to the administrator to set the default to local conditions. And all RH/Fedora uses mandatory security labels unless the administrator has disabled them.

There is no easy way around having a repository for the various systems. Even then, setting up a repository for use is not simple for the naive user. They STILL have to be an administrator.

Indeed. I therefore decided to not allow user X, to install an application - as a system wide program. That solved everything in 1 shot. No elevation necessary. Still remains that awkward feeling that I want to make it happen, as a try-out that is.

Use $HOME/.local/share/icons/hicolor/<icon-size>/apps/ and $HOME/.local/share/applications/ and then you do not need escalation (though you will only have a single user install).

Read these:
http://standards.freedesktop.org/bas...ec-latest.html
http://lists.freedesktop.org/archive...er/010025.html