-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: elevate command #29199
Comments
Yeah, I think this would make sense to add as a multi-call thingy. Probably on systemd-run. (but could also be on machinectl shell). Should probably follow syntax of sudo a bit, i.e. support |
Firstly, this sounds amazing! Not needing But second, how would allow-listing users work? Is it still based on a user's membership to the |
We'd defer that to PK, i.e. similar to |
FYI, I played with this 2 years ago: https://gist.github.com/pothos/73dd4f7694acc3b6bbed614438f6e2b1 (Note the "known issue" which you might run into as well) That said, Polkit still uses a setuid binary |
Hmm, how is that actually used? Is that something actually forked off client side? or is this something forked off by polkitd to be able to verify passwords? I can't find a clear explanation what it actually does and how it is used. |
This turns "systemd-run" into a multi-call binary. When invoked under the name "uid0", then it behaves a bit more like traditional "sudo". This mostly means defaults appropriuate for that, for example a PAM stack, interactivity and more. Fixes: systemd#29199
This turns "systemd-run" into a multi-call binary. When invoked under the name "uid0", then it behaves a bit more like traditional "sudo". This mostly means defaults appropriuate for that, for example a PAM stack, interactivity and more. Fixes: systemd#29199
The polkit agent prompts for password and passes it to See also: https://gitlab.freedesktop.org/polkit/polkit/-/issues/168 |
This turns "systemd-run" into a multi-call binary. When invoked under the name "uid0", then it behaves a bit more like traditional "sudo". This mostly means defaults appropriuate for that, for example a PAM stack, interactivity and more. Fixes: systemd#29199
This turns "systemd-run" into a multi-call binary. When invoked under the name "uid0", then it behaves a bit more like traditional "sudo". This mostly means defaults appropriuate for that, for example a PAM stack, interactivity and more. Fixes: systemd#29199
This turns "systemd-run" into a multi-call binary. When invoked under the name "uid0", then it behaves a bit more like traditional "sudo". This mostly means defaults appropriuate for that, for example a PAM stack, interactivity and more. Fixes: systemd#29199
Component
other
Is your feature request related to a problem? Please describe
Elevating privileges in Linux currently requires setuid. These tools thus need to be careful to distrust their input (where any bug == root access on system), isolate their environments, etc etc etc
Describe the solution you'd like
systemd introduces a new tool,
elevate
, that's basically behaves likesystemd-run
w/ a more palatable CLI. This lets thiselevate
tool be unprivileged, and it just asks a privileged client (systemd) to take some action for it.Describe alternatives you've considered
Discussed w/ @poettering @ ASG, and this is basically what we converged on
Name-wise: most things are named
*ctl
orsystemd-*
. This would break with the form. The name might be worth it, though 👀The systemd version you checked that didn't have the feature you are asking for
254
The text was updated successfully, but these errors were encountered: