No More Dolphin Root Workaround?

[jglen490]

I've probably used Dolphin as root maybe twice in all the time I've used Kubuntu distros. I've always used Dolphin to view root spaces, which has never been a problem, and maybe(?) will never be.

Unix gave us su and we have sudo in Linux. Midnight commander and others like it are O.K., but I hardly ever need it.

I guess I don't view messing with elevated permissions to be a big deal, or maybe I'm missing the point. And as the years go by, that's likely it

[WWDERW]

I've probably used Dolphin as root maybe twice in all the time I've used Kubuntu distros. I've always used Dolphin to view root spaces, which has never been a problem, and maybe(?) will never be.

Unix gave us su and we have sudo in Linux. Midnight commander and others like it are O.K., but I hardly ever need it.

I guess I don't view messing with elevated permissions to be a big deal, or maybe I'm missing the point. And as the years go by, that's likely it

To me, the core tenant of Linux is to use the system how you want to use it, any way that you want to use it. And yes, that does include using it in ways that may break the system, that is how one learns. There are times that I'm more efficient in using root in dolphin then via the CLI (or should I say more efficient with elevated rights, regardless if its su or sudo). That may not be for everyone and it may not truly be the technically more efficient method, but for my workflow, it is the more efficient method.

Now, that does not mean that I want to run my system in a perpetual state of su for any and all apps. It is still just a temporary status and once I am done, I no longer have need of it and I am no longer using the elevated privileges.

As to Commander/Krusader, while I have used those (well Krusader), I have no liking for them. If you (or anyone else) does that's fine, nothing wrong with that. I just get a headache everytime that I look at Krusader. I know some that just love it and that's great, I just prefer the overall experience with Dolphin far more and I never really liked having 2 file managers installed at the same time. That reminds me of one of the things that I didn't like with Windows in that if you didn't like one of the build in programs and you wanted to use something else, it had to be installed along side those integrated applications, which just wasted resources overall.

And while I could handle differences among them as far as features go, being able to run something in an elevated state, in my mind (and maybe I'm wrong), should just be something that I should be able to do if/when there is a need for it (regardless if that need is real or imagined).

Overall, I love the experience with Plasma. While there are still some decent size concerns that affect me and my particular setup when using Plasma (it doesn't seem to exist when using a Gnome based setup, although that setup has it's own concerns, just slightly different), overall I prefer this environment. This particular issue seems to be the biggest item left for me, and as long as that workaround works, in the end it shouldn't matter, I just don't believe that there should be a need for the work around in the first place. Otherwise, I really do love the experience of Plasma in Kubuntu (even on Neon that I use on my non mission critical stations).

[kubicle]

To me, the core tenant of Linux is to use the system how you want to use it, any way that you want to use it.

That's not how the "software freedom of open source" works. The developers are free to develop their software as they see fit, and users are free to modify the source code and/or use alternatives methods (or software) if they don't like the way that particular software works. That's the freedoms we have in Linux. Not the freedom to have everything we want handed to us. But it is open source, you *can* use it in "any way that you want to use it" (to remove the restrictions, it's just a few lines of source code edit and a rebuild...not that it is currently necessary, since you can use pkexec), you just can't tell someone to fix software A to behave like software B because you don't like software B.

And yes, that does include using it in ways that may break the system, that is how one learns

.
That sort of misses the point why the changes were made to dolphin. For example, when you start any GUI app as root, an unprivileged user or process can get root access to the machine through the inherent insecurity of the X protocol (and the way the app communicates with the X server), that's not really a "learning experience" most people using linux (for the sake of it's "improved security" over some alternatives) would expect to get. And the X insecurity is not easily fixable (without rewriting X), it's one of the reasons Wayland is being developed.

Based on my personal experience, 95% of users that run GUI apps as root (including the ones that identify as power-users) don't really understand the security issues involved, which is probably why the somewhat drastic step was taken by the dolphin devs (if they included a config option for that, most people would just enable that without ever thinking of or understanding the possible implications).

Of course different developers do have different priorities, and dolphin being the default file manager (with a more varied user base), it's developers are understandably taking a more cautious approach compared to krusader (which is more geared towards to the more advanced user base).

This doesn't mean I agree with the way the changes were implemented by the devs, IMO the policykit integration which would allow *secure* root operatios in dolphin (without actually running the app as root) should have been implemented first, but I respect the developers freedom to err on the side of security for the default file manager. (and yes, there are workarounds and alternatives, but all gui apps started as root currently suffer from the same security issues).

[Snowhog]

And don't forget, one of the things that developers were always plagued with, was being vilified (at worst) when someone severely borked their system running a GUI 'as root'. They were damned if they did; damned if they didn't.

kubicle is exactly right: Developers are free to develop their software as they see fit. They are after all, making it available to the user at the incredibly low, low price of "free".

[WWDERW]

And don't forget, one of the things that developers were always plagued with, was being vilified (at worst) when someone severely borked their system running a GUI 'as root'. They were damned if they did; damned if they didn't.

How a user uses the software is their own fault. Not the devs. If the users bellyache over it, that's their own problem. I have borked many a system and you know what, I learn far more from that then anything else.

kubicle is exactly right: Developers are free to develop their software as they see fit. They are after all, making it available to the user at the incredibly low, low price of "free".

If that's the case, then why all the bellyaching when MS limits what users can do with their OS? It's the same thing here. It's limiting. The biggest different here is that it goes against (in my mind) a core tenant of what it is to run Linux. Which is totally freedom to do what one wants with their system. Regardless if it's the smart thing to do.

I can understand if the feature didn't exist in the first place and they had their own reasons to not allow it. I could actually understand that. But this is a feature that did exist and was available that then was removed and it wasn't to make way for an even better feature that would have been at odds with this ability.

Now as to varied user base. Absolutely true. Here is the pickle, it was mentioned about changing source code to achieve desired result. Just how much of that user base would be able to actually do that and not run a high risk of mucking something up? I would say pretty good percentage, especially given the reasoning for removing root from the program in the 1st place when it was originally there. Why couldn't it have been implemented like how to get 'su' in *buntu? Something that takes a little more effort, but not something totally out there?

[Snowhog]

How a user uses the software is their own fault. Not the devs. If the users bellyache over it, that's their own problem. I have borked many a system and you know what, I learn far more from that then anything else.
.
.
.
Now as to varied user base. Absolutely true. Here is the pickle, it was mentioned about changing source code to achieve desired result. Just how much of that user base would be able to actually do that and not run a high risk of mucking something up? I would say pretty good percentage, especially given the reasoning for removing root from the program in the 1st place when it was originally there. Why couldn't it have been implemented like how to get 'su' in *buntu? Something that takes a little more effort, but not something totally out there?

(Emphasis added above) Whether or not any given user has the skills and abilities to 'change source code' isn't the developers problem and never should be. That Linux is about "freedom" doesn't mean that developers are required to take in to account the end users ability to actually use what they write in the way that they intended it to be used. What is true, and always will be, is that if any developer writes code that users don't like, eventually not enough users will use it and the developer will either change how it works to suit more users, or they will abandon it entirely.

[WWDERW]

Then why are devs concerned with users abilities or lack thereof when it appears to be the main argument for removing functionality that previously existed?

[kubicle]

How a user uses the software is their own fault. Not the devs. If the users bellyache over it, that's their own problem.

Says who? I personally would stay away from software whose devs would think like that, and I'm sure most people would be rather miffed if a browser emptied their bank account and the developers' response would be "well, you shouldn't have used it".

I have borked many a system and you know what, I learn far more from that then anything else.

Then I guess all the worries about software security can be thrown out the window, because there are users out there who have learned a lot by borking their systems.

If that's the case, then why all the bellyaching when MS limits what users can do with their OS? It's the same thing here. It's limiting.

It's most certainly not the same thing. With closed source software there is very little you can do about it, with open source software you can change it.

The biggest different here is that it goes against (in my mind) a core tenant of what it is to run Linux. Which is totally freedom to do what one wants with their system. Regardless if it's the smart thing to do.

You can do what you want with it, you can even run a GUI file management app as root (even dolphin) if you wish to do so...no one is stopping you. You're probably right that there are users out there that want/need to be spoon fed, but that is quite frankly their problem.

I can understand if the feature didn't exist in the first place and they had their own reasons to not allow it. I could actually understand that. But this is a feature that did exist and was available that then was removed and it wasn't to make way for an even better feature that would have been at odds with this ability.

When security issues are discovered, I'd expect the developers to try to mitigate them (even if they cannot be completely eradicated)...developers that prioritize software security are not going to keep insecure features just because it was there before.

Now as to varied user base. Absolutely true. Here is the pickle, it was mentioned about changing source code to achieve desired result. Just how much of that user base would be able to actually do that and not run a high risk of mucking something up?

Then that percentage of the user base probably shouldn't be doing that. I'd rather prefer my OS to be developed for the smart users, not the laziest (or the most ignorant) ones. You preach that it is the users' responsibility how they use their software, but at the same time seem to be opposed of them having to actually learn how to do that. Besides, wouldn't those users "learn a lot" by mucking something up? (your words, not mine)

Why couldn't it have been implemented like how to get 'su' in *buntu?

Probably because there is no way to securely run GUI apps as root under X. it's not the same in cli programs (which don't talk to the X server in the same way)...this is why policykit integration is being developed so that you can perform root operations in apps without actually running the gui app as root (the way it is handled in kate).

but not something totally out there?

Really? The current way of running GUI file managent as root (even with dolphin) is "totally out there"?? Because you don't like how Krusader looks? Because running dolphin with pkexec is totally undiscoverable without 5 seconds of google searching? Because there are users out there that cannot be bothered to actually learn how to use their systems?

EDIT: I apologize if I come across as unnecessarily harsh. But for a software developer, there are very few things that are as tiresome as all the different variations of "you should do this because that is how I want it done (nevermind that I'm not the one who is paying your salary)".

[WWDERW]

Says who? I personally would stay away from software whose devs would think like that, and I'm sure most people would be rather miffed if a browser emptied their bank account and the developers' response would be "well, you shouldn't have used it".

If one runs something in root, that's a risk that they have. If they can't be responsible with it, they have to learn. I see some people that do things that should know better that don't. What was that deal with Apache, a bug that was off by default, then a particular user turned it on to do something and then forgot to turn it off after they were do. I don't blame the devs for that. It was off to begin with. If the devs had left it on from default, that's another story.

Then I guess all the worries about software security can be thrown out the window, because there are users out there who have learned a lot by borking their systems.

Some don't learn from what they do. And if they don't, again that's on them. Sometimes the lesson isn't as apparent.

It's most certainly not the same thing. With closed source software there is very little you can do about it, with open source software you can change it.

May be able to change it. Some may not be able to. Again, no agree that's not the devs fault, but let's face it, having the source code out in the open is in theory great, but it is only practically great if one can actually do something with it.

You can do what you want with it, you can even run a GUI file management app as root (even dolphin) if you wish to do so...no one is stopping you. You're probably right that there are users out there that want/need to be spoon fed, but that is quite frankly their problem.

I don't think that's only other alternative out there, but I could be wrong.

Now, I do want to make sure that I'm not thought of as someone that has to be spoon fed, since I'm the major proponent on this. I've got cron jobs that I have to run due to the Wacom cintiq and how the new kernel does x or doesn't do x (and there are very few Cintiq users out there, so there isn't a quick good search for cintiqs specifically).

I don't mind the funky way of something small like getting translucent panels on Breeze Dark when despite all the available options that Plasma has, that isn't there (there may be a good reason for it, I haven't looked too much into that). I'm just point that out.

When security issues are discovered, I'd expect the developers to try to mitigate them (even if they cannot be completely eradicated)...developers that prioritize software security are not going to keep insecure features just because it was there before.

I don't consider this a security issue compared to something that I can't close off or I didn't have to actively initiate. If it's a zero day or something to where it's on, but should be off or vice versa, those would be security issues.

Then that percentage of the user base probably shouldn't be doing that. I'd rather prefer my OS to be developed for the smart users, not the laziest (or the most ignorant) ones. You preach that it is the users' responsibility how they use their software, but at the same time seem to be opposed of them having to actually learn how to do that. Besides, wouldn't those users "learn a lot" by mucking something up? (your words, not mine)

I think a lot of people assume that it's either one way or the other. If can't/don't want to handle it this way, then you must be one of "those".

I think that's missing out on a user base that just wants to get "stuff" done. Some come to Linux to just install and run and get work done. I don't think there is anything wrong with that, but maybe I'm apart of that lazy/ignorant faction. I would like to think that the 5 hrs that it took for me to come up with 3 lines of code to handle my Cintiq issue would have precluded that (this is just one example) and that eats into my work and getting stuff done, but that just might go into that lazy/ignorant faction. I dunno. Tell me your thoughts on that?

While I don't consider scripting things out the ying yang to be hard core dev work, it does impede working efficiency when the user is just trying to get work done.

Really? The current way of running GUI file managent as root (even with dolphin) is "totally out there"?? Because you don't like how Krusader looks? Because running dolphin with pkexec is totally undiscoverable without 5 seconds of google searching? Because there are users out there that cannot be bothered to actually learn how to use their systems?

I don't like the workflow of Krusader. I'm far more efficient in Dolphin/Nautilus/Nemo then I am in Krusader. I might be doing it wrong, I'm sure I am, but for my workflow, it isn't efficient.

EDIT: I apologize if I come across as unnecessarily harsh. But for a software developer, there are very few things that are as tiresome as all the different variations of "you should do this because that is how I want it done (nevermind that I'm not the one who is paying your salary)".

I honestly don't think that at all. This type of exchange is how a learn (for better or for worse). As far as software development for myself, Electron dev work would be my most involved work (I don't consider scripts anything to hollar about in regards as a developer) that I do and I do believe some devs don't even consider that dev work at all. So I may not do any dev work depending on which camp your in.

[TWPonKubuntu]

I've enjoyed following this discussion. For me, the bottom line of this thread, Dolphin having root access rights, is very important to my web design workflow. Now that pkexec is working (in 19.04 anyway), I'm back in the flow.

With respect to the philosophical argument about whether to shield users from potentially dangerous GUI actions or to allow those actions with a simple warning, there is no argument.

Let the user have access.

The warning needs to make it clear where the danger lies, but the user should not be completely blocked, as was the case with Dolphin before someone wrote the pkexec script (thank you).

This whole discussion is very likely to come up again, with other tools. It is the nature of Linux development that we will work through the blockages. I just hope it happens faster than this Dolphin situation because I lost work time=money.

Again, thanks for the very good discussion on the philosophy of software development.

[kubicle]

I don't consider this a security issue compared to something that I can't close off or I didn't have to actively initiate. If it's a zero day or something to where it's on, but should be off or vice versa, those would be security issues.

Therein lies the core of the problem. Maybe you are among the users that don't have other (unprivileged) users on your systems and never yourself run any software that you haven't examined the source and have built yourself, but I assure you that you are in a very small minority.
Let's say you have a user that has installed something from the internet in their $HOME (or possibly you have done so yourself), that software could run a daemon that listens to the X server waiting for an admin user to come along and run a GUI app as root, and bam, that daemon has root (no input necessary from the admin user, other than the act of starting the gui app as root). That is a real security issue. If you understand that, and make an informed decision to run a gui root app, that's quite fine by me (but most people do not quite grasp that, even when I've tried to explain it to them...at least not the ones who search for the quick instructions, and I can assure you that a warning of "this is dangerous" doesn't quite do it either).

Tell me your thoughts on that?

I certainly didn't want to imply that I consider you to be either lazy or ignorant (not that I consider either to be necessarily bad things or mutually exclusive to being smart). And I'm probably one of the laziest people you'll find north of the south pole (and quite ignorant of many things). I meant that the idea that I thought you are promoting: "that all software should be developed so that everyone should be able to do everything with it, without having to learn anything and regardless of security concerns" would mean that software would be catered just to those that are the laziest and/or most ignorant, and I don't think that is in the best interest of anyone, not even those that are lazy and/or ignorant...at least not in the long run.

[WWDERW]

Therein lies the core of the problem. Maybe you are among the users that don't have other (unprivileged) users on your systems and never yourself run any software that you haven't examined the source and have built yourself, but I assure you that you are in a very small minority.

I'm actually in a far smaller minority then that I would imagine. I prefer to run very lean installs and I prefer to use portable programs then traditionally installed programs (be it through the package manager or through a run file or a install script etc). Even when I create my Electron apps, I still build them as AppImages or as binary archive for Win users. But you are correct in your assessment that my systems are single user systems.

I totally agree with your scenario, but that would also be an issue with any GUI program and there are some that I do believe would require root access to do what they needed to do.

[kubicle]

but that would also be an issue with any GUI program and there are some that I do believe would require root access to do what they needed to do.

Absolutely. But apps can have root access (with policykit) without running them as root. We probably all know (by now) how kate can perform write operations with elevated privileges when necessary while running the gui as normal user (no one really complains about the kate workflow anymore). And Gnome has recently added the admin:// gvfs protocol that enables apps like gedit and nautilus to do the same.

So it is was a judgement call for the devs...and different devs made different decisions (there were no strictly right or wrong decisions here). Like I said previously, I probably would have gone with the decision the krusader devs made, but I wouldn't criticize dolphin devs for the decision they made either, there are good strong arguments to support either choice, especially considering the different user bases and the fact that policykit integration is necessary anyway in the future wayland era.

And I honestly believe the dolphin decision might have been different if it was known at the time that it would take 2+ years to get policikyt integration in kio (after all policykit support was finished rather quickly for ktexteditor which kate/kwrite uses), as we know pkexec support was later enabled to restore the root workflows (it needed some changes in the source code to lift the strict restrictions a bit), but hindsight is always perfect.

Currently, AFAIK, the only thing blocking the release of enabled polkit support in dolphin is this: https://phabricator.kde.org/T8075 (so it should be fairly close, and should improve all workflows and add immediate security benefits while also being ready for wayland).

[WWDERW]

Absolutely. But apps can have root access (with policykit) without running them as root. We probably all know (by now) how kate can perform write operations with elevated privileges when necessary while running the gui as normal user (no one really complains about the kate workflow anymore). And Gnome has recently added the admin:// gvfs protocol that enables apps like gedit and nautilus to do the same.

I'm actually an odd duck on that. For simple edits of files that need root access, I've always used Nano and that was never an issue (of which you had outlined why previously). I'm a huge fan of Kate, but when I just need some quicky config edits, I usually default to Nano.

However, I do think, depending on how some programs are launched may not go thru policykit. I can't say for sure, they still might, it's just not readily apparent to me and usually it is apparent (as in pop up window), that's why I'm speculating this.

So it is was a judgement call for the devs...and different devs made different decisions (there were no strictly right or wrong decisions here). Like I said previously, I probably would have gone with the decision the krusader devs made, but I wouldn't criticize dolphin devs for the decision they made either, there are good strong arguments to support either choice, especially considering the different user bases and the fact that policykit integration is necessary anyway in the future wayland era.

I always try to approach changes in a way that impacts the user the least. Sure there may still be "teething" problems, but which method involves that the least. It doesn't always work out that way though, sometimes what was originally thought of the least impactful method, may indeed be the opposite. As you said, hindsight is always 20/20.

[jglen490]

So there seems to be some late breaking news about changes in the KDE landscape coming in 2020. These changes might give some relief to Dolphin users and elevated permissions.