-
-
Notifications
You must be signed in to change notification settings - Fork 34
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
fix: support to other privilege elevation programs. #92
fix: support to other privilege elevation programs. #92
Conversation
Forgot to mention that it will Fix #59, but it still uses |
I also tested on NixOs Unstable with doas installed. Works fine for me. edit: Ok i also tried to clean, which still doesnt work with doas and this pr. Cleaning calls self_elevate which still uses sudo. |
I'll look into the clean command and fix it |
Seems like the self elevate function is only using @Makesesama If you could test it I would be very grateful. |
Seems to work now |
Thank you! |
You might also be interested in adding run0 support. Related post: https://mastodon.social/@pid_eins/112353324518585654 |
systemd is currently at version 255.4 in NixOS unstable so I'll refrain to add it until it is actually released, but I'll look into it when it is available |
An alternative is to allow for some way for the user to specify what privilege escalator to use. This would be easier if This would allow for forcing |
Now that systemd v256 is out and currently being reviewed for eventual merging into nixpkgs, will this be updated to add support for run0 |
I'll update everything with the suggestions, thank you! |
I guess I could add Now I'm not sure where in that list it should be included, considering that it will be installed in every systemd based system, I think it should be low in the list, maybe above Also, it should probably check for a environment variable to determine what to do for convenience, just like |
Any ideas on how that would look like in the command line? I added a way to specify a custom privilege elevation binary to use, but I cannot think of a way to add the extra command line arguments. Maybe another flag would work, but that seems messy to me. A config file would be optimal, both for the |
b9bc8e1
to
a663db2
Compare
a663db2
to
b651383
Compare
Systemd 256 was merged into staging-next and should be in master and unstable very soon. I would appreciate run0 support |
@deviantsemicolon run0 support was already added! Testing would be appreciated. |
If the nixpkgs maintainers ever get around to merging the next staging-next thing, where the systemd 256 PR is, into master, then I might be able to see what I can do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@henriquekirchheck i disabled sudo and ran nix run to test your code. I got an error regarding setting a locale and it asked me to reauthenticate a few times, but that could be a nix run issue. not sure though. Other than that, it did use run0 as expected, so LGTM
the error basically said it couldn't set a locale and fell back to a standard one called "C"
@deviantsemicolon this issue is normally related to localization, and considering my code is basically just calling a different program it doesn't feel related. I'm not currently able to test it myself, but I'll try to do it asap. |
I'm also getting the localization warnings mentioned above. My best guess is it's related to the environment differences w/ The only real issue I see is that w/
On the positive side, the automatic coloring of output from the elevated subprocesses from UpdateYeah, I've verified this by writing a quick script: #!/bin/sh
exec run0 --setenv=LOCALE_ARCHIVE $@ And then using that as the elevation provider: ❯ nh os switch -e "$(pwd)/test.sh"
> Building NixOS configuration
warning: Git tree '/home/caleb/git/nix' is dirty
warning: input 'nixos-hardware' has an override for a non-existent input 'nixpkgs'
Finished at 13:05:07 after 0s
> Comparing changes
<<< /run/current-system
>>> /tmp/nh-os-zOvtIc/result
No version or selection state changes.
Closure size: 2610 -> 2610 (0 paths added, 0 paths removed, delta +0, disk usage +0B).
> Activating configuration
activating the configuration...
setting up /etc...
reloading user units for caleb...
restarting sysinit-reactivation.target
the following new units were started: libvirtd.service
> Adding configuration to bootloader Update 2Installing the following in Home Manager run0Wrapper = pkgs.writeShellScriptBin "run0" ''
exec ${pkgs.systemd}/bin/run0 --setenv=LOCALE_ARCHIVE $@
''; |
You can use any elevation program with |
I would like the ability to set a default in settings so I don't need to type run0 and -R everytime. It also does not work on my system, and outputs an error saying it can't find the NixOS configuration, even when specifying the directory my flake is in. |
Please send the actual log with |
|
this worked with the PR perfectly fine. |
I think that |
This pr adds support for both
doas
andpkexec
, while keeping support forsudo
.For this to work, I decided that the cleanest way to implement this was by adding a extra parameter to the Command struct that specifies if the command should be ran as root or not. When the root parameter is set, it checks for the existence of
doas
,sudo
, andpkexec
, in that order, and uses it to run the command by prefixing the command invocation arguments with the respective program when it is constructed.The specified order was chosen because I believe that if someone has
doas
installed in their system, it's more likely that they use it as their main privilege escalation program. ´pkexec´ was added more as a fallback in case someone doesn't havedoas
orsudo
.This was tested in my NixOS Unstable system with both
sudo
anddoas
, but I haven't testedpkexec
personally.