Open RokeJulianLockhart opened 9 months ago
Very well explained.
The main development team behind YaST (which includes me) is aware of the issue and I personally share your view and would like to move to a more modern approach.
That been said, I don't see that happening in the short term if it depends on the current development team. We have MANY tasks with higher priority in our to-do list. But we are of course open to collaboration if someone is brave enough to open that can of worms.
https://github.com/yast/yast-yast2/issues/1293#issuecomment-1755155467
Thank you, @ancorgs. I was worried when I posted this that it wouldn't be received well. I too understand the undertaking necessary to switch to an approach like this - I'll contribute toward it when I'm a competent enough developer to.
Although minor improvements like https://github.com/yast/yast-yast2/issues/1132#issue-792088442 (as described at https://discuss.kde.org/t/why-doesnt-kde-su-provide-invocation-info-like-policykit-does/5884/4?u=rokejulianlockhart) would certainly be a minor improvement to initial permission elevator necessary when invoking YaST, it doesn't remediate its fundamental mismanagement of the permission granted to it: YaST should request permission from the superuser (or any other user) solely when it's performing an action in which such permission is necessary, not a second before.
This isn't security theatre nor unnecessary hardening, it has tangible benefits for every user:
The appearance configuration would be respected when using YasT
This might appear as if it's a minor consideration, but it would be a very, very significant boon for accessibility. For instance, I find non-monospace fonts less legible, and light pages at night really quite painful. Because my font and colouration configuration obviously don't carry over to the superuser's account unless manually synchronized, I must indeed manually duplicate my preferences over there.
No auth necessary for non-privileged actions
Authentication wouldn't be necessary to view data that isn't protected by a higher authority, nor would it even be necessary to launch the application. This would provide more non-dangerous tools to unprivileged users on a corporate (or personal) system.
PolicyKit
Because this would be a brilliant time to move to PolicyKit (per the aforementioned https://github.com/yast/yast-yast2/issues/1132#issue-792088442) it would provide the user with obvious confirmation that each time they provide permission for an action, it's actually for that action.
Currently, it's the difference between
and