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

[Azrael5]

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

[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.

[Nth_man]

KDE Ends 2022 [...]

About how KDE ended 2021:

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

[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.

[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 think its ridiculously naive to claim that Linus's video had no impact. Yes the work has been ongoing but the amount of traction that Linus brings put that specific issue higher on the priority list and this was even admitted by KDE developers on reddit in response to his video.

In reality the core complaint that Linus had is correct, which is that from a purely non advanced user experience point of view the situation was terrible and telling people to "use a CLI instead" completely misses the point.

If the Linus video wasn't made then it may have taken another couple or so years to push that final 20% to get it out.

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.

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.

[cjcox]

Let's give a hand to Michael with next year's article: " KDE Ends 2022 With More Plasma Wayland Fixes..."

I'm still laughing at all the people that down voted me for saying Wayland wouldn't be "default everywhere" by end of 2019 (!)

[markg85]

This shows something that you never understood the problem.

Kali Linux a security distribution made all the same kind of arguments you did about being only a single user running as root would be fine. Yes they found for wifi attacks and so on running with root capabilities was faster but they also found when it goes wrong the stuff goes wrong in a big way.

Running kodi as root with all capabilities (privileges) and something goes wrong instead of being a simple restart the system fix as it would have been as a normal user its a complete reinstall possible with complete data loss. Yes the power of the root granted .

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.

https://securityboulevard.com/2020/0...-on-kali-2020/ Yes it took them until 2020 to change it. Of course you still have users forcing their way back as running as root and not understanding the level of danger they are playing with.

The hard reality is running any more than you need to as root is not a good idea and will cause you trouble at some point or another.


do take a look at capabilities some time.

You will find something dangerous when you are running with

https://man7.org/linux/man-pages/man7/capabilities.7.html

Yes CAP_SYS_ADMIN is the privilege we really do align with root operations and do note the nightmare here is not properly defined. Problem is this alters even how the OOM Killer responds to the application. and what memory and disc space you are allowed to allocate. Yes allowed to allocate without the normal safe guards so you could be forcing the kernel to suspend kernel processes that should be happening your process to proceed that would have just shared processing time and proceed in background if you were not with CAP_SYS_ADMIN..

The fault has been seen for over 20 years now. The problem is security related and it does not require multi users as such because the Linux kernel behaves different between a normal user account/non capability process and a root/capability granted process..

Linux root for capabilities granted is closest user on MS Windows user is SYSTEM. Do note under windows you normally cannot log in as system. Yes administrator account under windows are not the most privileged account you can see it at times when there are in use files that windows administrator account cannot delete but if you are running as windows SYSTEM user or using a tool running a bit as Windows SYSTEM user you can. Yes at time when stuff goes wrong with a process running windows system user it can be a reinstall as well.

Like it or not users running applications normally don't need the full rights to-do everything. That everything is ultra broad and has many downsides.

Early Late 1990s early 2000 it was found running graphical applications as root/privilege capabilities resulted in different behavour on Linux and early 2000 it was found that this different behavour could have adverse effects. Yes this reality people keep on wanting to ignore.

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

The 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.

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.

[mdedetrich]

The answer is no Linus video did not change anything about the speed. Security of stuff like this takes while.

I think its ridiculously naive to claim that Linus's video had no impact. Yes the work has been ongoing but the amount of traction that Linus brings put that specific issue higher on the priority list and this was even admitted by KDE developers on reddit in response to his video.

In reality the core complaint that Linus had is correct, which is that from a purely non advanced user experience point of view the situation was terrible and telling people to "use a CLI instead" completely misses the point.

If the Linus video wasn't made then it may have taken another couple or so years to push that final 20% to get it out.

[bug77]

Let's give a hand to Michael with next year's article: " KDE Ends 2022 With More Plasma Wayland Fixes..."