_How_to_reproduce_ 1) Click a listed package, its information is then shown in lower part of the window. There: 2) Click "Details" For many packages there is then a URI displayed i.e for LibreOffice it is http://www.libreoffice.org/ 3) Click that link, and the default internet browser starts _as_root_ ! _What_should_happen_ a) At best: open that link as the regular user logged into current desktop b) Alternatively: just do not start browser. User can easily copy/paste the link to his browser User can today select it as normal text, or right click that link Possibly simplify use so normal left click directly copies the link. This is not new, but i have not seen anyone reacting to it before. I set it as Major as i think it is a bad idea to run web browser as root, especially while not warning the user.
CC: (none) => pkg-bugsAssignee: bugsquad => thierry.vignaud
Same problem in manatools
CC: (none) => anaselli
CC: (none) => yves.brungard_mageiaSummary: Security: Clicking links in drakrpm opens them in web browser *as root* ! => Security: Clicking links in drakrpm and manatools opens them in web browser *as root* !
Well you are supposed to have given the root password to run rpmdrake or rpmdragora as root to install packages, so you should know you have root rights at that point, i don't think you've not be warned :) As it is by now, rpmdrake and rpmdragora need to be root to install and remove, rpmdragora can be run as user, and should work for queries (it could be buggy of course...). If they were running using dbus api... maybe the could run in user space and require authentication just when installing or removing packages, not so now. I will take a look at this problem anyway... as soon as possible.
I understand the teckicalities somewhat, but as a user i think I gave root password in response to a queistion about running installer - not web browser... I f it can not (easily) be changed so it opens the link as the desktop user, then i think it is best it do not open at all. Possibly just putting the URI on clipboard.
Summary: Security: Clicking links in drakrpm and manatools opens them in web browser *as root* ! => Security: Clicking links in drakrpm and rpmdragora opens them in web browser *as root* !
well you can also run rpmxxx as root from konsole... so i don't know if in that case you can understand which user is running it
This is a bug since mandriva so..
Yes and i have always copy pasted the links... Is it only me who thinks it is a bad idea to run firefox as root?
This is a bug that should be fixed. That it dates back to Mandriva does not mean that it's not relevant, just that nobody fixed it so far :)
Well mcc tries hard to guess the right user if run from the menu. If run from a terminal as root already that's more difficult. Any idea for improvements is welcome...
(In reply to Thierry Vignaud from comment #8) > Well mcc tries hard to guess the right user if run from the menu. > If run from a terminal as root already that's more difficult. That's a good point. I guess we could assume: - If the user was logged as root (su -) when running MCC, it's OK to open links in the browser as root. - If the user ran MCC via the menu or via `drakconf` from a user terminal (i.e. polkit had to ask for the password), we should try to use this information to load the browser with the user session. Would that be doable?
That's what mcc is already trying to do :-) See: http://gitweb.mageia.org/software/control-center/tree/control-center#n610 http://gitweb.mageia.org/software/drakx/tree/perl-install/run_program.pm#n154 http://gitweb.mageia.org/software/drakx/tree/perl-install/run_program.pm#n200 Fee free to suggest any improvements...
I suspect USERHELPER_UID is no more set since Colin switches us to usermode to polkit... Can you try replacing it by PKEXEC_UID in /usr/lib/libDrakX/run_program.pm and try again mcc from menu?
Keywords: (none) => NEEDINFO
(it's in my local git tree)
*** Bug 8526 has been marked as a duplicate of this bug. ***
CC: (none) => Konrad.Bernloehr
Depends on: (none) => 11125
please check if new manatools is ok. @Thierry i seem to understood that getpwnam does not work correctly with uid, while it does with username...
Manatools patch: http://gitweb.mageia.org/software/manatools/commit/?id=66340bb7fccd8a6556f77c1648be4bb62cc11ddd @Angelo: you should use "mga#12345" instead of "Bug#12345" to get a nice automatic notification made in the bug report.
Maybe it should launch browser only if it is another than root? -to avoid ever launching a web browser as root.
@Remi i always forget it :| @Morgan if you run tools as root you should know that you are root, you can always run a browser... i would avoid to change the behavior for root user. our raw routine already try to understand which user is running the program and use it to change setuid.
Just for reference while I see this, the correct solution here is to *never* run the GUIs with root privs in the first place. The correct approach is to separate GUI from the backend tasks via defined services (likely controlled over dbus). polkit can be used to give permissions to use those services happily (it integrates with dbus well). This way you don't have to guess anything, the user context will still be in place when you click links etc. So the correct solution is not to work out who the original user is, and get back to that user session... it's to never leave it in the first place. (for reference see lots of the GNOME tools which need higher privileges which do so on demand - e.g. adjusting time or user login details - the big "Unlock" button triggers polkit authorization)
CC: (none) => mageia
commit 1446f4ac0b364c041d7de0e5a186e9709a300388 Author: Thierry Vignaud <thierry.vignaud@...> Date: Fri Jun 3 17:40:42 2016 +0200 uid guess: fix the fallback (mga#18288) (when the helper didn't provide the real UID) --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=1446f4ac0b364c041d7de0e5a186e9709a300388
commit 97a49721274c5538f121811195e802669424c316 Author: Thierry Vignaud <thierry.vignaud@...> Date: Fri Jun 3 16:14:18 2016 +0200 guess the right user after the switch to polkit adjust the env variable to look at (mga#18288) --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=97a49721274c5538f121811195e802669424c316
Fixed in git
Status: NEW => RESOLVEDResolution: (none) => FIXED
Thanks Thierry Yes Colin that would have been beautiful :)
commit c47fbdbfe731d38a3207deaae0bc8d199365766d Author: Angelo Naselli <anaselli@...> Date: Mon Aug 8 15:28:17 2016 +0159 used $ENV{PKEXEC_UID} as in rpmdrake mga#18288 --- Commit Link: http://gitweb.mageia.org/software/manatools/commit/?id=c47fbdbfe731d38a3207deaae0bc8d199365766d
Links are still opened in a browser run as root, at least from a Wayland GNOME session.
Status: RESOLVED => REOPENEDCC: (none) => davy.defaudResolution: FIXED => (none)
Actual status update: When i start dnfdragora from KDE Plasma launch menu or from Konsole, it do not ask for root password, and when i click links in packages descriptions they open in users browser. Good :) (it ask for root password when i tell it to execute) When i launch mcc (or drakrpm directly) or mpan from KDE Plasma launch menu *they immediately ask for root password*, I then select rpmdrake/manatools and when I click links in packages descriptions, Firefox is launched as root! (i removed NEEDINFO as i did not see any feedback requested)
Keywords: NEEDINFO => (none)
dnfdragora does not need to be root to be executed for install purpose, so yes all is run as user. iirc rpmdragora tries to run firefox as the user who originally run it, before giving password, but that code is pretty similar to rpmdrake, so if it is not working for the latter, it isn't for the first either