Allow changing program to be used by pmm as sudo

[aeknt]

This pr adds config value [pmm] sudo which can be used to change sudo program to for example doas.

Not sure if the flags -u should part of the config value. Doing so would perhaps allow more flexibility.

I don't know awk very well so it might be completelly wrong but it seems to work on my machine.

[aeknt]

Also should be doas.conf added [global] etc by default? It works but doas has to be configured to have keepenv setenv { PATH } to work properly.

[paradigm]

I agree we should make this configurable. In retrospect I'm surprised I didn't do so when first writing this subsystem.

I'd rather not make the configuration item called sudo - I think that'd be confusing for exactly the target audience of this change that doesn't want sudo. How about this:

• Add a new configuration item under [pmm] called drop-privileges-command and have it default to sudo -u $SUDO_USER.
• Remove the old unprivileged-user item from the default bedrock.conf, as the new one effectively replaces it.
• Ensure we're backwards compatible with older bedrock.confs by having pmm first check for and use drop-privileges-command. If it's unavailable, check for and use unprivileged-user pairing it with sudo.
• In /bedrock/share/pmm/package_managers/* replace ${unprivileged_user} with ${drop_privileges_command}.

Also should be doas.conf added [global] etc by default?

Ideally yes. However, a quirk in how 0.7 works means adding it will make the global instance shadow over every stratum's individual instance. Essentially, it'll hide preexisting doas.conf instances, which will be very confusing for some users.

The proper way to handle this is to move the existing doas.conf elsewhere before making it global, then move it back. You're welcome to do this to your own system now. However, many users may not know to plan ahead for this and lock themselves out of root permissions needed to fix it if we make it a proposed default on preexisting installs.

I'm reworking the configuration system in 0.8 to make the behavior around adding new global items less surprising.

It works but doas has to be configured to have keepenv setenv { PATH } to work properly.

0.7 doesn't have good automation to automatically configure this, and trying to add some now is a bit risky as if it doesn't work it could lock people out of root permissions needed to undo the change. Improving the auto-configuration subsystem is another goal for 0.8.

[aeknt]

Sounds like good plan, i'll try implement that

[aeknt]

This seems to work, any thoughts?