Bug 387974 - Allow Dolphin to be launched when logged in as root user (NOT sudo'd in a user session)
Summary: Allow Dolphin to be launched when logged in as root user (NOT sudo'd in a use...
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 17.08.3
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords: usability
: 388119 390434 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-12-16 23:08 UTC by Nate Graham
Modified: 2018-05-31 18:18 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In: 18.08.0
Sentry Crash Report:


Attachments
attachment-6683-0.html (805 bytes, text/html)
2018-02-17 20:03 UTC, michael
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2017-12-16 23:08:43 UTC
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.
Comment 1 林博仁(Buo-ren, Lin) 2017-12-16 23:32:29 UTC
There's literally no usecases of running a session as root in the first place.
Comment 2 Nate Graham 2017-12-16 23:34:33 UTC
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.
Comment 3 Elvis Angelaccio 2017-12-23 10:25:35 UTC
*** Bug 388119 has been marked as a duplicate of this bug. ***
Comment 4 Nate Graham 2018-02-14 17:50:03 UTC
*** Bug 390434 has been marked as a duplicate of this bug. ***
Comment 5 michael 2018-02-17 18:58:10 UTC
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.
Comment 6 Nate Graham 2018-02-17 19:16:58 UTC
Thank you! Would you consider doing the same for Kate? Bug 387973
Comment 7 michael 2018-02-17 20:03:32 UTC
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.
Comment 8 Andrius Štikonas 2018-02-18 12:43:29 UTC
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.
Comment 9 David 2018-02-18 12:51:49 UTC
(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.
Comment 10 Andrius Štikonas 2018-02-18 13:11:50 UTC
(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.
Comment 11 michael 2018-02-18 13:48:55 UTC
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.
Comment 12 michael 2018-02-18 13:53:25 UTC
On a more productive note. Is there a well known user id dolphin could deescalate to in circumstance?
Comment 13 Nate Graham 2018-02-19 22:17:50 UTC
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).
Comment 14 Chris 2018-03-24 19:02:12 UTC
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?
Comment 15 Nate Graham 2018-05-31 18:18:29 UTC
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