This came up in https://bugs.kde.org/show_bug.cgi?id=179678#c37 As a part of implementing PolKit support, Dolphin was prevented from running with root privileges via sudo, which is fine. Unfortunately, now Dolphin also doesn't launch when you're actually logged in as the root user. This is probably not necessary since if you're already the root user, privileges aren't really an issue anymore. It's worth mentioning that this isn't a Wayland or PolKit restriction; GNOME's Nautilus can be launched when logged in as the root user, even in a Wayland session.
There's literally no usecases of running a session as root in the first place.
One came up in https://bugs.kde.org/show_bug.cgi?id=179678: penetration testing. Besides, that's an argument for distros to disable the root account, not for DEs to selectively disallow certain pieces of software from running in a root user session.
*** Bug 388119 has been marked as a duplicate of this bug. ***
*** Bug 390434 has been marked as a duplicate of this bug. ***
I have a patch in the works that will resolve this issue. It will allow running logged in as root but still block sudo. IMO that block should be done through /etc/sudoers but since we're going this way.
Thank you! Would you consider doing the same for Kate? Bug 387973
Created attachment 110755 [details] attachment-6683-0.html Yes should be the same fix for both. On Feb 17, 2018 2:17 PM, "Nate Graham" <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=387974 > > --- Comment #6 from Nate Graham <nate@kde.org> --- > Thank you! Would you consider doing the same for Kate? Bug 387973 > > -- > You are receiving this mail because: > You are on the CC list for the bug.
Why would we allow running dolphin as root. We are trying to prevent user from even starting a single GUI application running as root. And here the suggestion is to use the whole session as root. That's much worse security wise than single GUI app.
(In reply to Andrius Štikonas from comment #8) > Why would we allow running dolphin as root. We are trying to prevent user > from even starting a single GUI application running as root. And here the > suggestion is to use the whole session as root. That's much worse security > wise than single GUI app. As for why: for example, when you need to modify permissions of files and folders, copy/delete files in certain directories, edit system stuff, among others. By restricting users to launch Dolphin as root, you are not making people more secure. You are just annoying people by making their workflow less convenient and forcing them to use a different application to do the job, such as Nautilus or Pluma. Consider that one of the reasons why some people use KDE and its apps in the first place is because they are sick from other DE's attitude of thinking they know better than their users how they should do stuff.
(In reply to David from comment #9) > (In reply to Andrius Štikonas from comment #8) > > Why would we allow running dolphin as root. We are trying to prevent user > > from even starting a single GUI application running as root. And here the > > suggestion is to use the whole session as root. That's much worse security > > wise than single GUI app. > > As for why: for example, when you need to modify permissions of files and > folders, copy/delete files in certain directories, edit system stuff, among > others. > > By restricting users to launch Dolphin as root, you are not making people > more secure. You are just annoying people by making their workflow less > convenient and forcing them to use a different application to do the job, > such as Nautilus or Pluma. > > Consider that one of the reasons why some people use KDE and its apps in the > first place is because they are sick from other DE's attitude of thinking > they know better than their users how they should do stuff. By the way, it wasn't me who disabled running Dolphin as root, it was Martin Flösser but I think he would object to a patch like this. All of these tasks could be done with Polkit. Copying/deleting files with KAuth is almost done in KIO. Kate already supports editing system file with KAuth, you just open file in Kate, edit it, and when you save it, you are asked for password. Changing permissions sound like a fairly simple KAuth helper. I know form the developers perspective it's simpler not to use KAuth. Martin was telling me since maybe two years ago not to use root for KDE Partition Manager. And as you can imagine Partition Manager really needs root for almost every single thing it supports, no other GUI app in KDE needs root in so many places. Yet over the last year I with some help from other people were porting it to use KAuth and we are getting close.
So why is it the domain of DE's and system designers to protect users from themselves through enforced sand boxing of this nature? Warn them yes. Make it secure by default fine but don't hard code this kind of thing. Distro's and system admins already have access to things such apparmor and selinux which limit application activity even under root. Further docker uses a restrict root as its default user. This change in dolphin should not have gone down without the appropriate kauth support being added. Security at the expense of flexibility and the push for mandatory sand-boxing by the system are what drove me to Linux in the first place. Wayland already has forced developers to reevaluate what they are doing by blocking this kind of access. That is where enforcement needs to happen otherwise it is trivial to bypass the restriction with another gui based program if need be a custom designed one.
On a more productive note. Is there a well known user id dolphin could deescalate to in circumstance?
No one's arguing in favor of running dolphin sudo'd in a user session. But until root login is completely disabled, people are going to run GUI software in their root sessions, andpreventing Dolphin from running doesn't actually increase security at all, it just annoys them. ** Obviously root sessions should be strongly discouraged. ** No disagreement there. But that's not our call; Distros make that decision. And there are probably a few use cases that we can't think of, because our users have diverse needs. For example, root sessions using Docker are common. I think it's quite a reasonable compromise to allow Dolphin to run in a root session--if root sessions are allowed--but continuing to disable running Dolphin sudo'd in a user session (in favor if running it normally and using polkit for file activities requiring authentication).
If they feel it's so bad to run the whole process as su, I'm fine with it. Devs know best. But why in the name of all that makes logical sense would you disable it before implementing the new auth flow? Now it just plain doesn't work for creating, moving, copying setting permissions on system files! Now I'm just using a different su process that I like less simply because Dolphin has no working method that I'm aware of anymore. How does that make any sense? Get the user mode system to work, then disable sudo mode. How is that not the obvious strategy?
Git commit 40453cb627a39f1ff92373f865426f0bcdc83419 by Nathaniel Graham. Committed on 31/05/2018 at 18:18. Pushed by ngraham into branch 'master'. Re-allow running Dolphin as the root user (but still not using sudo) Summary: Prohibiting the use of Dolphin as the actual root user (not using `sudo` or `kdesu`) breaks legitimate use cases for using the root user. An example is Kali, a distro that logs in as the root user by default as a deliberate design choice. In such an environment, there is no additional security vulnerability beyond what you're already potentially exposing yourself to. So, let's re-enable it. FIXED-IN: 18.08.0 Test Plan: - Log in as normal user and run `sudo dolphin`: you get an error message. - Log in as normal user and run `kdesu dolphin`: you get an error message. - Log in as the root user and run dolphin normally: it works. Reviewers: markg, elvisangelaccio, #dolphin Reviewed By: markg Subscribers: chinmoyr, cfeck, elvisangelaccio, mmustac, Fuchs, markg, graesslin, nicolasfella, zzag, kfm-devel, emmanuelp Tags: #dolphin Differential Revision: https://phabricator.kde.org/D12795 M +8 -3 src/main.cpp https://commits.kde.org/dolphin/40453cb627a39f1ff92373f865426f0bcdc83419