KDE Ends 2021 With More Plasma Wayland Fixes, Root File Operations For Dolphin

[mdedetrich]

Until you check the priority list. Yes what is written in reddit and what happened are two different things. The feature was priority for the next major KDE release from 2019.

Again, actual KDE developers said otherwise, it was repriotized (whether it was "officially" done via bug tracker is another story). It got more attention than it normally would have which means it came out faster.

Yes Linus tech tip videos had effects and they were not all positive. Like the recent merge due to Linus tech tip video caused spam is 4 weeks behind because the merge review request got lost in spam. So yes KDE developers are fairly media aware. Yes the post on reddit was more about stopping a disaster of operation disruptions that if it was not brought under control was going to push the late KIO polkit feature even latter. The reality there was no where high to go on the priority list than where KIO polkit was before Linus tech tips made their videos.

KIO polkit is need on the Wayland side and on the user mode only x.org X11 server as it does not accept connections from different user out box. This problem was detailed in 2019. Getting it working right has been the major problem.

There are still over 100 known code quality faults to fix in the KIO polkit code to fix yet. Hopefully none of them are deal breakers.

Overall the net effect was positive, the initial release may not be perfect but it can be iterated on and improved over time.

[oiaohm]

I don't buy those arguments.
What you say there can also happen as a user.

The only reason (i can think of) that would justify running it as a user is to make it more fool proof. That as a reason would be acceptable as it makes it easier for tech savvy users to run such an application. As root you might need to get warnings about that. Let the user know that it's not the advised way etc... but not forbid it.

The reality here is MS Windows basically forbids you from using SYSTEM. Changes to allow x.org X11 server to run as user also result in not being able to sudo applications simply. Yes working with wayland you start running into some of the same problems.

IThe problem i have with this paranoid security that happened back then was the urge to immediately fix it while it was very much an edge case and not that likely to be widely exploited. A fix (with polkit) was known back then too but the whole stack wasn't ready for it. Hence it taking so long till it finally landed.

The proper way would have been to leave it "broken" and inform the users that it's not advices to run it as root. Then get working on the proper fix to transition from one mechanism to the other. Not to bluntly nuke the root route (now only the sudo route) and stay in that state for years till the polkit route has gotten enough support.

There's also a lot of blame to place on the security folks here too. Fine if they do research and find holes. They do often also point out where that hole is and what a fix could be. Thus far they did a fine job. But it stopped right there. The solution was to nuke a feature. Not to properly explain how the hole could be dangerous. Not to poke the right people (polkit ones) to let them know that a proper fix would be to get polkit widely adopted. And yes, i do expect the security researchers to do that! They put in the time to find holes, let others fix their findings then also put in the effort to at least make the fix as minimally invasive as possible. Aka, NOT to nuke a feature but to get it working without the issue persisting.

There is a big problem here it was not security folks who found this problem. It was security people who worked out what the problem really was but end users had been opening bug reports over data loss. So this is exploit in wild not exploit in theory.

Exploit in wild means you have to counter measures.

II do (or did) understand it perfectly fine. That's over 10 years ago.
I surely don't vividly remember the exact details.

No this is works for me answer. This ignores uses who open bug reports who had lost data and had other really bad things happen. Yes this ignores the security people report that there is no way you can be sure that dolphin as sudo is safe based off what the different users had run into. The dolphin has too many features to be running as root/sudo. So every time you would sudo Dolphin you are basically rolling a dice on your system and crossing fingers it does not come the snake eyes killing your system.

Remember markg85 dolphin file-manger does at time crash.

https://bugs.kde.org/buglist.cgi?bug_severity=crash&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&order=bug_id%20DESC&product=dolphin&query_format=advanced

Yes when I looked at this there are 84 open crash bugs. Do you really fell lucky here that none of these crashes with higher capabilities is not doing to do worse than just crash. I can tell you there are some in there that will do worse. Yes safe to happen when lower capabilities not safe with the extra capabilities that sudo/root provides.

Granted, i've only very rarely been in the position where i actually needed a graphical Dolpin ever since it became impossible to run as sudo. I think only once or twice.

This part of the issue why it could be disabled it is not a commonly need feature. When people are end up with total disasters and its a rarely need feature and there is another way to perform the task common security thing todo is remove the feature.

Please note KDE delayed the disabling of the dolphin sudo until Gnome files worked for the task using polkit. So terminal or gnome files(already using polkit at this stage) could do the job safely. So users could still do their tasks graphically ok they had to use gnome parts but data safety wins over a little inconvenience.

Also developing the new polkit interface they need to know in more details what people in fact need to-do as higher capabilities user. Yes you can attempt to survey people but that generally does not work(there is a phone that a classic example of this failure) now of you break their workflow and read the bug reports you get a lot more correct data as well. So there was a second reason to be a pain in the ass here. Security meant they should disable the feature and disabling the feature would get them the feedback to make the replacement.

Yes Linus of Linus tech tips did find gnome files and it did work to perform the task without need to run gnome files complete as root./sudo risks of a highly complex graphical application.

markg85 the hard reality here majority of security faults are not found by security people attempting to find faults instead come from software developers users reporting bugs and developers asking security people to look at what is going on to assist developing a fix.

[Nth_man]

KDE Ends 2022 [...]

About how KDE ended 2021:

Highlights from 2021
https://pointieststick.com/2021/12/3...hts-from-2021/

[oiaohm]

Again, actual KDE developers said otherwise, it was repriotized (whether it was "officially" done via bug tracker is another story). It got more attention than it normally would have which means it came out faster.

Saying something and doing something are two different things. The is only 1 developer assigned to code the KIO polkit stuff.. That person number of hours working on KIO polkit did not change at all for 3 years. So there was no real prioritisation change of the development. Yes the review also number of hours on polkit did not change a single bit.

So said it was repriotised but nothing changed in the coding development side. There was a repriotisation but its not where you were thinking

Overall the net effect was positive, the initial release may not be perfect but it can be iterated on and improved over time.

Sorry you are wrong the over all effect was in fact a negative. The repriotisation was not on developing the KIO polkit feature it was cleaning the bug tracker out of spam around the bugs the review of the polkit work and the developer of the polkit work so people spamming the issue system were not getting in the way.

Its one thing to put a spot light on a issue but we have to work out someway to put a spotlight on a issue that does not end up spamming the developers trying to make it work.

Yes people want to think that something like Linus tech tips would have a positive effect the reality is it had zero effect other than those attempting to manage the problem using careful wording so they said they repriotised something around KIO polkit and everyone nicely run with that the development work has to be speed up slowed down the spam and so bug tracker triage people had been repriotised away from other bugs to control the spam that would not have existed without the video.

You could call your so call claim of net positive to be nothing more than a placebo effect that you fell for hook line and sinker. When you did into what in fact happened that it was triage people reallocated noting todo with the code development of KIO polkit changed other than the channel of communication between the writer of the Polkit code and reviewer of the polkit code being disrupted by spam caused by the video.

Now that video could have been a positive if people had put up more resource to develop the feature instead of spam complaining. Yes lot of claims of don't bother with the polkit integration just allow the file manager to run as root that had already been covered many times over.

The problem here is the Linus Tech Tips video was not exactly useful. Yes spotted a user issue then published it massively without explain exactly why KDE was going the polkit route particular that there was no other choice long term. The requirement for wayland and X.org X11 server running as user both do not like graphical applications running as root. Also there are stability issues running as root that are well documented.

The problem here is from the Linus Tech Tip video set a stack of unformed people lose on the KDE issue system and end up causing disruption instead of any help.

It would be a different matter if there were more developers working on the KDE polkit feature or the developer doing the KDE polkit work got more hours to work on it but this did not happen. The reality is the development of KDE polkit stuff did not change in any positive way from the Linus Tech Tips video.

Lot of ways it does not pay to sugar coat what happened here. Smaller projects would not have had the resources to handle this. Even so people who have reported true problems end up being slower seen to. Reality that Linus tech tips video was a net negative nothing has happened that would not have happened anyhow.

The question that need to be answered is there any way in future to handle stuff like this and not cause major problems. Maybe Linus of Linus tech tips should have open a issue on the KDE issue system and gave his user a link to there so that their complaints and issues did not end up disrupting the development work in a major way? Remember smaller project would not have has the resources to handle the people hitting the issue system in this way.

The people who miss behaved is why that video should not be giving any credit for anything positive or they will do it next time as well to possible a smaller project that cannot handle it.

[Azrael5]

Kde developers should separate Neon based on x11 and Neon based on wayland replacing kwin with a wayland vulkan compositor.

[markg85]

There is a big problem here it was not security folks who found this problem. It was security people who worked out what the problem really was but end users had been opening bug reports over data loss. So this is exploit in wild not exploit in theory.

Exploit in wild means you have to counter measures.

Interesting that this comes to light ~10 years after the fact.
I'm quite sure that, at the time, there certainly was not a single case of it happening in the wild.
Be aware with whatever you're going to claim here that i was in fact in the review for Dolphin (just as one of the reviewers) and to my knowledge there was no real life situation at all besides a proof of concept showing it "can be done".

I challenge you to find a single bug report from before dolphin was patched showing that dolphin caused loss of data due to this very specific bug as you claim there was. I'll buy you a beer if you find one and you'll get that beer if i ever see you in real life. (quite unlikely but not impossible as i did attent KDE conferences in the past)

But till you've proven that, i don't believe your statement that there were reports of users losing data because of this very specific bug! And don't pull up a bug report page with users "losing data" and claiming those reports are a result of this security hole. You better be specific with bug reports that actually proof the security issue was abused and causing the loss of data.

Remember markg85 dolphin file-manger does at time crash.

https://bugs.kde.org/buglist.cgi?bug_severity=crash&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&order=bug_id%20DESC&product=dolphin&query_format=advanced

Yes when I looked at this there are 84 open crash bugs. Do you really fell lucky here that none of these crashes with higher capabilities is not doing to do worse than just crash. I can tell you there are some in there that will do worse. Yes safe to happen when lower capabilities not safe with the extra capabilities that sudo/root provides.

Please don't do this. You're now pulling up crash issues and are reasoning about general "higher capabilities". They have absolutely 0 todo with the issue we were discussing here! We were talking about the very specific "security hole" from ~10 years ago, not elevated permission in general. Stick to that one issue please.

This part of the issue why it could be disabled it is not a commonly need feature. When people are end up with total disasters and its a rarely need feature and there is another way to perform the task common security thing todo is remove the feature.

Please note KDE delayed the disabling of the dolphin sudo until Gnome files worked for the task using polkit. So terminal or gnome files(already using polkit at this stage) could do the job safely. So users could still do their tasks graphically ok they had to use gnome parts but data safety wins over a little inconvenience.

And that right there is a very destructive opinion in open source land.

If i'm using KDE and am forced to use a Gnome tool (where i otherwise would use nothing from gnome at all) is a massive pain. Personally i'd much rather go the command line route (which completely bypasses all this security btw) and copy my files that way then to install Nautilus (gnome files these days?). I am very much against that mentality because it's not as simple as you make it look like. Just running another tool is fine (i do that on the command line too). But suggesting a tool that's part of a different desktop environment has the nasty side effect that it likely pulls in hundreds of extra dependencies. Now that's a potential security issue on it's own.

Sidenote, on ubuntu an action like that is really dangerous. Ubuntu has the nasty habit of enabling services you installed. If you install Nautilus (and therefore much of gnome) you now have more services running then you had before. I get that from a user friendly point of view. I personally hate it as i like to be in control of what's running. For me it's not an issue as i'm on Arch where such "user friendly" behavior is non-existent.

[markg85]

Kde developers should separate Neon based on x11 and Neon based on wayland replacing kwin with a wayland vulkan compositor.

You're either totally ignorant or just a troll. For the sake of the argument i'm hoping for the best in people thus i'd guess you're totally ignorant.
If you even think that kwin can be swapped out with another compositor then you just don't know what kwin is and what it does.

Kwin is very much tied into how you experience KDE/Plasma. It doesn't only handle your window placements and input handling. It also handles - for example - the miniature application view when you hover over it in the taskbar, it handles the thing you see when pressing ALT+TAB and it does a lot more.

KWin has a compositer internally and they are working on a wayland one. I'm not sure if there's any vulkan in the mix there though.

start sarcasm
But i see that you, with your hyped statement, have time left and an abundance of knowledge of how it should be done?! How great, a visionary! I'm sure you don't mind helping the nice KDE folks out, put you money where your mouth is, and start contributing?! More help is always welcome!
end sarcasm

[sheldonl]

Please note there are still code quality issues to fix. So still possible to be pulled before final release at this time.

The 10 years of this work is been merged 8 times and reverted 7 times. lets hope it does not come 8 times reverted.

According to the comments thread on nate's blog, it was pulled over code quality issues and delayed to a "future release"

[markg85]

According to the comments thread on nate's blog, it was pulled over code quality issues and delayed to a "future release"

Ahh, really! hahahaha
It has in fact been reverted for 5.90: https://invent.kde.org/frameworks/ki...ts/v5.90.0-rc2

It broke quite a few testcases.
The code is still alive in the master branch where it's being fixed. So that's going to be 5.91

[bug77]

About how KDE ended 2021:

Highlights from 2021
https://pointieststick.com/2021/12/3...hts-from-2021/

I know, I'm using it every day. For a short while was even usable on Wayland, but then GBM support landed and now everything is super slow.

Also, despite that link, this barely changed in 2021: https://community.kde.org/index.php?...d_Showstoppers
Granted, it's heavy stuff in there and some of it is not under the control of KDE developers. But in the absence of any other roadmap, that's how I judge Wayland support.