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

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

[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!"

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

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