Why doesn't KDE su provide invocation info like PolicyKit does?

rokejulianlockhart · October 8, 2023, 2:13pm

One of the things I love about PolicyKit is that it provides the information necessary to decide whether to provide or deny authorization to a process.

However, why is it that KDE su doesn’t do the same?

Screenshot_20231008_151023

ngraham · October 8, 2023, 3:05pm

It does provide invocation details; it tells you what command will be run as root. That’s all it does, it runs a command as root. It’s just a GUI for sudo, really.

rokejulianlockhart · October 8, 2023, 5:55pm

I was hoping for something like an Action parameter, but I was probably silly to expect that that was generated based upon the context rather than manually stated by the developer.

Would the solution in this case to be to request that YaST use PolicyKit, @ngraham?

Not su -c?

Herzenschein · October 8, 2023, 8:29pm

I think you might want pkexec instead of kdesu?

Offtopic but the YaST issue already exists, to signal your interest you can give it a thumbs up: Add a policykit policy that allows yast to run via pkexec · Issue #1132 · yast/yast-yast2 · GitHub

With pkexec you’re still running the whole app as root until you close it, it’s not such a great improvement aside from the nicer window. Better would be for the app to request your user password whenever a root operation is needed, but that needs to be implemented in the app itself.

Angus · October 8, 2023, 9:21pm

yup, su -c .

github.com

KDE/kdesu/blob/8b7a35c3e36b8b1bee37a6957de295db4aa6d32e/src/suprocess.cpp#L129


      
          if (d->isPrivilegeEscalation()) {
              args += "-u";
          }
          
          if (m_scheduler != SchedNormal || m_priority > 50) {
              args += "root";
          } else {
              args += m_user;
          }
          
          if (d->superUserCommand == QLatin1String("su")) {
              args += "-c";
          }
          // Get the kdesu_stub and su command from a config file if set, used in test
          KSharedConfig::Ptr config = KSharedConfig::openConfig();
          KConfigGroup group(config, "super-user-command");
          const QString defaultPath = QStringLiteral(KDE_INSTALL_FULL_LIBEXECDIR_KF) + QStringLiteral("/kdesu_stub");
          const QString kdesuStubPath = group.readEntry("kdesu_stub_path", defaultPath);
          args += kdesuStubPath.toLocal8Bit();
          args += "-"; // krazy:exclude=doublequote_chars (QList, not QString)

Edit: OMG - nice expansion of the github link to a greppy -C10

rokejulianlockhart · October 9, 2023, 1:37pm

God, I’d love that. However, the YaST guys seem to be of the mind that radical changes like that are never the solution over incremental ones, so I’ve been dreading making an issue for it. I’ll try though, considering they appear receptive to that one.

rokejulianlockhart · October 9, 2023, 1:52pm

github.com/yast/yast-yast2

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

opened 01:52PM - 09 Oct 23 UTC

RokeJulianLockhart

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 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. 1. #### **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. 1. #### **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 > ![image](https://github.com/yast/yast-yast2/assets/42837531/df42655f-8f92-42dd-aa43-48409bc6e334) and > ![image](https://github.com/yast/yast-yast2/assets/42837531/199c5c09-41d4-4f14-a5fe-6115e141a50d)