Open jedenastka opened 5 days ago
Polkit already has this feature and you can experience it e.g. when giving password to gnome-control-center for e.g. printers.
It's called auth_admin_keep (see man polkit
, section DECLARING ACTIONS). Each action specified by a package vendor in appropriate .policy file (located usually in /usr/share/polkit-1/actions/
) can be defined as auth_admin_keep, so that you don't have to write down your password every time. This decision is on the vendor of the package that defines the actions (systemd in your case).
@poettering, any comments?
Doesn't that only work for a single process requesting multiple actions? I tried editing my configuration to use that before, and it didn't work - ArchWiki states that is the reason for it. run0
or systemctl
run only once, and then exit, as they are CLI tools. The next request comes from a new process.
Polkit already has this feature and you can experience it e.g. when giving password to gnome-control-center for e.g. printers. It's called auth_admin_keep (see
man polkit
, section DECLARING ACTIONS). Each action specified by a package vendor in appropriate .policy file (located usually in/usr/share/polkit-1/actions/
) can be defined as auth_admin_keep, so that you don't have to write down your password every time. This decision is on the vendor of the package that defines the actions (systemd in your case). @poettering, any comments?
We already set auth_admin_keep for the action run0 uses. Alas it doesn't work, PK seems to invalidate the cache whenever a process exits and run0 is pretty short-lived.
Any chance this can be relaxed? if you don#t want to drop the flushing of the permission cache entirely, then maybe bind it to the inode of the binary of the process rather than the PID?
or in other words, allow cached permissions if either:
Would that make sense?
btw, polkit's "pkexec" tool is in the same boat here as run0, it's also short-lived and thus currently cut out of any caching of permissions.
(of course, reading /proc/$PID/exe is a bit racy, since pids might be recycled asynchronously. if pk has a pidfd of the client this can be dealt with nicely: simply check if after reading the stat() data the pidfd still points to the same pid (and not 0), and you verified that the process didn't exit in the meantime and the pid hence didn't possibly get recycled yet, and the stat() data you read of that file definitely is still correct.)
Is your feature request related to a problem? Please describe. When running security-sensitive actions such as managing services via
systemctl
, Polkit asks me to authenticate, which is not a bad thing, but I will often run many such actions in a row, requiring me to retype the password over and over (remember that a secure password should consist of multiple words).The well-known utility
sudo
also deals with a security-sensitive action (running as root), but it remembers the password for a configurable amount of time (15 minutes by default), for a given session (a different session will be asked for the password even in that period; not sure how a session is determined bysudo
, but the important part is that a single shell process is counted as a single session). Ironically, this makes me often runsystemctl
assudo systemctl
, since root is not prompted for a password by Polkit (I assume this is the upstream configuration, though I use the Debian package). This is a pretty stupid workaround, but seems like many do it anyways just because of this usability issue.This is even more important with the addition of a
run0
utility to the systemd suite, which is meant to be a cleaner, safer alternative tosudo
based on the existing underlying systemd security system, including Polkit. While it does a quite good job,run0
will now ask you for the password every time you run something as root, because that's what Polkit does. Sincesudo
offered the capacity to remember the password, this is a roadblock torun0
adoption, at least in my case, and I imagine many others.Describe the solution you'd like Add a way to configure a period of time during which Polkit will remember the entered password for this session, default to 15 minutes like
sudo
. A session in CLI should encompass still using the same shell process, in whatever way this is done, in GUI it should mean using the same desktop session. This could still require confirmation, as described in #463.With this, there are a few issues with the CLI authentication prompt itself:
run0
, which only purpose is to run things as other users (which is security sensitive) probably should be considered enough confirmation by itself (enteringy
and enter every time would still be pointless, though better than the current situation). This seems problematic to do properly with Polkit, and it has no analogue in the GUI world.Those would probably better be explored in separate issues, however.
Describe alternatives you've considered
Additional context I think the utility of admin passwords should really be reconsidered, as described by my comment in #463. Still, it would be good to see this as an option for people that prefer having them, or just simply if having confirmation-only authorization be the default is not currently (or ever) considered desirable.
@poettering Curious about your thoughts, since you seemed excited for
run0
to take over the world ;) and probably have a better idea about how this should be done to benefit systemd tooling. Seems risky to ping, but pinging the entire systemd project would be worse, especially considering my previous issue...