Change Details

I'd like to revisit the issue of not allowing Dolphin to run with elevated privileges, and make the case that the way this change was implemented was user-hostile and sub-optimal. I would also like to propose an alternative in patch form. == Ideological/correctness arguments == - It's not appropriate for software at the DE level to make judgments about how the user has chosen to run it or what kind of user account they're using. In terms of the OSI model, this would be like a web app on the Application layer refusing to run when the Transport layer is TCP, or the Network layer is IPSec. If there's a security vulnerability at the X11 level, it should be fixed there. - There is no reason to prevent using Dolphin as the root user (not sudo). Using Dolphin with the root user account is no more insecure than any other GUI software executed as the root user, since X11 is already being run as the root user. The current implementation fails to make this distinction and therefore aggravates people who need or want to use KDE Plasma with the root user. == Practical arguments == - Distros like Kali use KDE Plasma and boot to a root GUI session by default (and by design). //For users of this distro, Dolphin simply doesn't work at all.// The same goes for recovery distros the boot into the root user. It's not reasonable to entirely break these use cases. - Since the feature was disabled, we've received a [[ https://bugs.kde.org/show_bug.cgi?id=179678#c6 | neverending ]] [[ https://bugs.kde.org/show_bug.cgi?id=387974 | stream ]] [[ https://phabricator.kde.org/T8460#137351 | of ]] [[ https://www.reddit.com/r/kde/comments/5l35db/how_can_you_enable_root_access_in_dolphin/ | criticism ]] that demoralizes KDE developers, takes up the time of KDE bug triagers, and generates negativity on social media that discourages people from using our software. - openSUSE has patched out the change; when a major enterprise distro undoes your work, it might be worth listening to them and considering whether the change might have been ill-considered/ == Usability and user-friendliness arguments == - It is user-hostile to disable a feature before its replacement (PolicyKit support in KIO) is available. - The current method of implementation is user-hostile: a message is only printed to the console, and if a GUI method is used to run Dolphin with sudo or as root, there is no indication of why it doesn't work. Dolphin just looks broken, and we look bad. --- For all of these reasons, this patch reverts the previous implementation that disabled running from root and with sudo, and instead replaces it with more nuanced check that distinguishes between when Dolphin is run as the root user and when it's run as the current user via sudo. It displays an orange warning message in the GUI instead of prohibiting the program from running. Once PolicyKit support is enabled in KIO and released to users, I think it might be reasonable to once again prohibit running Dolphin with sudo (but not as root) as long as we provide a GUI message to cover the case where Dolphin-with-sudo is launched via a desktop file, as is common with many old "open this folder with administrator privileges" add-ons that people may still be using.

I'd like to revisit the issue of not allowing Dolphin to run with elevated privileges, and make the case that the way this change was implemented was user-hostile and sub-optimal. I would also like to propose an alternative in patch form. == Ideological/correctness arguments == - It's not appropriate for software at the DE level to make judgments about how the user has chosen to run it or what kind of user account they're using. In terms of the OSI model, this would be like a web app on the Application layer refusing to run when the Transport layer is TCP, or the Network layer is IPSec. If there's a security vulnerability at the X11 level, it should be fixed there. - There is no reason to prevent using Dolphin as the root user (not sudo). Using Dolphin with the root user account is no more insecure than any other GUI software executed as the root user, since X11 is already being run as the root user. The current implementation fails to make this distinction and therefore aggravates people who need or want to use KDE Plasma with the root user. == Practical arguments == - Distros like Kali use KDE Plasma and boot to a root GUI session by default (and by design). //For users of this distro, Dolphin simply doesn't work at all.// The same goes for recovery distros the boot into the root user. It's not reasonable to entirely break these use cases. - Since the feature was disabled, we've received a [[ https://bugs.kde.org/show_bug.cgi?id=179678#c6 | neverending ]] [[ https://bugs.kde.org/show_bug.cgi?id=387974 | stream ]] [[ https://phabricator.kde.org/T8460#137351 | of ]] [[ https://www.reddit.com/r/kde/comments/5l35db/how_can_you_enable_root_access_in_dolphin/ | criticism ]] that demoralizes KDE developers, takes up the time of KDE bug triagers, and generates negativity on social media that discourages people from using our software. - openSUSE has patched out the change; when a major enterprise distro undoes your work, it might be worth listening to them and considering whether the change might have been ill-considered/ == Usability and user-friendliness arguments == - It is user-hostile to disable a feature before its replacement (PolicyKit support in KIO) is available. - The current method of implementation is user-hostile: a message is only printed to the console, and if a GUI method is used to run Dolphin with sudo or as root, there is no indication of why it doesn't work. Dolphin just looks broken, and we look bad. - Our userbase largely consists of technically competent users who //hate// being told that they can't do something "for their own good" that they know is technically possible. We haven't won any friends with this change. --- For all of these reasons, this patch reverts the previous implementation that disabled running from root and with sudo, and instead replaces it with more nuanced check that distinguishes between when Dolphin is run as the root user and when it's run as the current user via sudo. It displays an orange warning message in the GUI instead of prohibiting the program from running. Once PolicyKit support is enabled in KIO and released to users, I think it might be reasonable to once again prohibit running Dolphin with sudo (but not as root) as long as we provide a GUI message to cover the case where Dolphin-with-sudo is launched via a desktop file, as is common with many old "open this folder with administrator privileges" add-ons that people may still be using.

I'd like to revisit the issue of not allowing Dolphin to run with elevated privileges, and make the case that the way this change was implemented was user-hostile and sub-optimal. I would also like to propose an alternative in patch form. == Ideological/correctness arguments == - It's not appropriate for software at the DE level to make judgments about how the user has chosen to run it or what kind of user account they're using. In terms of the OSI model, this would be like a web app on the Application layer refusing to run when the Transport layer is TCP, or the Network layer is IPSec. If there's a security vulnerability at the X11 level, it should be fixed there. - There is no reason to prevent using Dolphin as the root user (not sudo). Using Dolphin with the root user account is no more insecure than any other GUI software executed as the root user, since X11 is already being run as the root user. The current implementation fails to make this distinction and therefore aggravates people who need or want to use KDE Plasma with the root user. == Practical arguments == - Distros like Kali use KDE Plasma and boot to a root GUI session by default (and by design). //For users of this distro, Dolphin simply doesn't work at all.// The same goes for recovery distros the boot into the root user. It's not reasonable to entirely break these use cases. - Since the feature was disabled, we've received a [[ https://bugs.kde.org/show_bug.cgi?id=179678#c6 | neverending ]] [[ https://bugs.kde.org/show_bug.cgi?id=387974 | stream ]] [[ https://phabricator.kde.org/T8460#137351 | of ]] [[ https://www.reddit.com/r/kde/comments/5l35db/how_can_you_enable_root_access_in_dolphin/ | criticism ]] that demoralizes KDE developers, takes up the time of KDE bug triagers, and generates negativity on social media that discourages people from using our software. - openSUSE has patched out the change; when a major enterprise distro undoes your work, it might be worth listening to them and considering whether the change might have been ill-considered/ == Usability and user-friendliness arguments == - It is user-hostile to disable a feature before its replacement (PolicyKit support in KIO) is available. - The current method of implementation is user-hostile: a message is only printed to the console, and if a GUI method is used to run Dolphin with sudo or as root, there is no indication of why it doesn't work. Dolphin just looks broken, and we look bad. - Our userbase largely consists of technically competent users who //hate// being told that they can't do something "for their own good" that they know is technically possible. We haven't won any friends with this change. --- For all of these reasons, this patch reverts the previous implementation that disabled running from root and with sudo, and instead replaces it with more nuanced check that distinguishes between when Dolphin is run as the root user and when it's run as the current user via sudo. It displays an orange warning message in the GUI instead of prohibiting the program from running. Once PolicyKit support is enabled in KIO and released to users, I think it might be reasonable to once again prohibit running Dolphin with sudo (but not as root) as long as we provide a GUI message to cover the case where Dolphin-with-sudo is launched via a desktop file, as is common with many old "open this folder with administrator privileges" add-ons that people may still be using.