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

[oiaohm]

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.

https://gitlab.com/kwinft/kwinft

Really it is possible that kwin will be swap with another compositor. Ok another kwin fork where things are done really different.

Please note kwinft is using wlroots a lot on the wayland side to see if this is a option to long term reduce workload.

Please note a fork of kwin coming the mainline kwin has happened to KDE twice in the past. So developer put forwards the work coding and then a choice will be made.

So yes it possible that if kwinft is really successful that in some future version of KDE the current kwin development will get scraped and replaced by kwinft. Of course another fork could happen and different item win.

[Azrael5]

You want them to do something that you deem "the right way".
You might be right, who knows. But it's a massive task to do what you suggest that they just don't have the manpower to do.

That's why i say: "put your money where your mouth is". You can do that by contributing yourself. And as you apparently know it so well, it should be peanuts for you to offer them some help.

There's no arrogance in that from my side at all.

Just a "little" thing you need to know about how KDE works. It's a bit of a meritocracy meaning that if you do the work you have a say in it. Or in other terms, code talks not words. You can shout all you want, if you don't submit the work to back your opinion up then it's just that, your opinion with no value behind it. It's a bit of a harsh truth but it is how open source development works in most projects and how it thrives.

Your answer confirm the limitation of your mind, indeed I wrote the sentence as hypothesis: "Kde developers should separate...". Kde developers have to do nothing for me or for others... A suggestion doesn't mean a personal advantage or an obligation. A suggestion normally simply exposes an own thesis. A thesis could aim to make better the object of the thesis itself. Could the thesis be wrong? Sure. Could be the suggestion not realizable in the current and actual context? Sure.
Your main mistake is to feel negative purposes where there aren't and to personally accuse others when your ideas are different or in contrast. Face with thesis confuting them with other thesis instead of offending people with whom you disagree.

[markg85]

The ignorant is just you. Indeed, Kde developers explain the reason why they prefer to stay on Kwin instead of integrate e new compositor. Separating PLASMA based on wayland from PLASMA based on xorg, the possibility to implement a new wayland compositor is an option to evaluate. If they expose the reason to apply Kwin also for Wayland environment, it means that they have assessed the possibility to change compositor. This is their explanation that you ignore because of arrogance:

You want them to do something that you deem "the right way".
You might be right, who knows. But it's a massive task to do what you suggest that they just don't have the manpower to do.

That's why i say: "put your money where your mouth is". You can do that by contributing yourself. And as you apparently know it so well, it should be peanuts for you to offer them some help.

There's no arrogance in that from my side at all.

Just a "little" thing you need to know about how KDE works. It's a bit of a meritocracy meaning that if you do the work you have a say in it. Or in other terms, code talks not words. You can shout all you want, if you don't submit the work to back your opinion up then it's just that, your opinion with no value behind it. It's a bit of a harsh truth but it is how open source development works in most projects and how it thrives.

[Azrael5]

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

The ignorant is just you. Indeed, Kde developers explain the reason why they prefer to stay on Kwin instead of integrate e new compositor. Separating PLASMA based on wayland from PLASMA based on xorg, the possibility to implement a new wayland compositor is an option to evaluate. If they expose the reason to apply Kwin also for Wayland environment, it means that they have assessed the possibility to change compositor. This is their explanation that you ignore because of arrogance:

"Why not a new Compositor?


Given that KWin was designed as a X11 Window Manager and later as a X11 compositor the question is valid, why not to implement a new Wayland compositor from scratch. Most parts of KWin are X11 independent. E.g. the Desktop Effect system is able to integrate Wayland clients without any change, the same is true for Window Decorations and other parts.

Another reason is that the KWin development team does not have the manpower to maintain an independent X11 window manager and a Wayland compositor. Starting a new Wayland compositor would mean to stop the work on the X11 window manager, which would be a bad move as we cannot know yet whether Wayland will succeed and will be supported on all hardware. Also in future KDE will have to provide an X11 window manager.

KWin is known as one of the most feature complete and most stable window managers. More than a decade of development effort has gone into this Window Manager. Reaching feature parity in a new Wayland compositor seems hardly possible if rewritten from scratch.

Writing a new Wayland Compositor would require to rewrite the complete X11 workspace in one go. This includes not only the Window Manager, but also parts of Plasma, Screen Locker and many, many more. This would take a long development time and the transition would not be smooth, very likely buggy and with regressions like the 4.0 introduction. We do not want to break the desktop!"

[oiaohm]

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.

Why dolphin should not be running as root is a general elevated permissions problem. This is not a fault is not a security hole. But in the way the security system functions with a set of known faults. Elevated permission of CAP_SYS_ADMIN grants what ever is running with it to go into the reversed disc space on some file systems and
CAP_SYS_RESOURCE grants it on others of course default sudo or default running as root you have both. That is right when a partition reads 100 percent its not really 100 percent full under Linux. This means the system should soft land so data be recoverable in most cases. This is not the only reserved allocation. Now you have a program running with Elevated permissions of cap_sys_admin its large and it goes wrong.

Lot of the times the crashes appear harmless as root user given capabilities.

Lets say you modify dolphin to drop capabilities that it really should not have if that happened dolphin running as root would not be as much of a major risk .

CAP_CHOWN,. CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_SETFCAP and possible CAP_FSETID is all you should need for a plain file manager. Except dolphin is not just a file manager it has integrated terminal and other things.

https://blog.container-solutions.com/linux-capabilities-in-practice#creating

Yes it possible to create a wrapper to assign those capabilities to dolphin running as your normal user. Yes if you did you might be very surprised that the majority are not doing anything as dolphin that really does need the full set privileges.

Now there are a set of problems.
1) dolphin is not designed to run privileged be it Linux/Freebsd .....
2) dolphin does contain means to display what privileges it running with.
3) dolphin does not have code to drop any privileges it will never need.

Please note all this privileges handling is platform particular code. Even under OS X and Windows there are ways to drop OS granted privilege you don't need.

Yes other than the polkit work no one has been stepping forward todo it. Yes disable sudo did get a developer to work on the polkit work.

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.

No going the command line path you are using smaller programs that rarely crash and if they do crash they normally use a very small amount of resources because they are not large programs.

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

Not only a few test cases the automated bot that scans for code quality issues found a stack of coding defects as well.

So on to round 9.

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

[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

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

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

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