Request superuser access solely when performing elevated action, rather than to run entire app.

[roke-julian-lockhart]

Although minor improvements like #1132 (comment) (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 elevation 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:

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

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

3. PolicyKit

   Because this would be a brilliant time to move to PolicyKit (per the aforementioned Add a policykit policy that allows yast to run via pkexec #1132 (comment)) 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

   

[ancorgs]

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.

[roke-julian-lockhart]

#1293 (comment)

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.

[shundhammer]

https://bugzilla.suse.com/show_bug.cgi?id=1216178