Skip to content
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

Automatically detect XBPS_SUCMD if not set #38075

Open
paper42 opened this issue Jul 14, 2022 · 7 comments
Open

Automatically detect XBPS_SUCMD if not set #38075

paper42 opened this issue Jul 14, 2022 · 7 comments
Assignees
Labels
enhancement New feature or request xbps-src xbps-src related

Comments

@paper42
Copy link
Member

paper42 commented Jul 14, 2022

XBPS_SUCMD is used for example for build updates with update-sys. Currently it's set to sudo sh -c in etc/defaults.conf, but we could comment it out and automatically detect common privilege escalation tools - sudo, doas, su (?).

@paper42 paper42 added enhancement New feature or request xbps-src xbps-src related labels Jul 14, 2022
@github-actions
Copy link

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.

@github-actions github-actions bot added the Stale label Oct 13, 2022
@paper42 paper42 removed the Stale label Oct 13, 2022
@github-actions
Copy link

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.

@github-actions github-actions bot added the Stale label Jan 12, 2023
@paper42 paper42 removed the Stale label Jan 12, 2023
@paper42 paper42 self-assigned this Jan 12, 2023
@Clos3y
Copy link
Contributor

Clos3y commented May 16, 2023

I'd love to see this implemented! Would something as naive as

SUCMDS=( su sudo doas )

for prog in "${SUCMDS[@]}"
do
[[ $(command -v $prog) ]] && export XBPS_SUCMD="$prog sh -c"
done

work? I don't know what other privilege escalation tools people use, but at least with these three, you can be mostly assured that if someone has doas installed, they're probably using it.

@classabbyamp
Copy link
Member

you need to check if there's a matching rule for sudo/doas too, see what xtools does for some things

@Clos3y
Copy link
Contributor

Clos3y commented May 16, 2023

you need to check if there's a matching rule for sudo/doas too, see what xtools does for some things

Taking this from xi

which_sudo() {
	if [ "$(id -u)" = "0" ]; then
		return
	elif command -v sudo >/dev/null && sudo -l | grep -q -e ' ALL$' -e xbps-install; then
		echo sudo
	elif command -v doas >/dev/null && [ -f /etc/doas.conf ]; then
		echo doas
	else
		echo su
	fi
}

putting it into the header of xbps-src, and changing xbps-src:1003 to XBPS_SUCMD="$(which_sudo) sh -c" bulk_update works. Seems to be the only place XBPS_SUCMD is used too at the moment.

EDIT: forgot that su would need to be treated differently, so it should probably be echo su root -c not echo su.

@Duncaen
Copy link
Member

Duncaen commented May 16, 2023

please don't put this anywhere where it will be executed each xbps-src invocation. There are tools that execute xbps-src in a loop on many packages to gather dependencies and each fork is expensive, this function would add a bunch of forks for something that is only required for one sub command.

Edit: I guess putting it on line 1003 would be fine. Generally I would prefer less magic or a way to disable this magic and put it where its required i.e. the bulk.sh file instead of adding it to the main script.

@Clos3y
Copy link
Contributor

Clos3y commented May 17, 2023

Generally I would prefer less magic or a way to disable this magic

What do you mean by less 'magic', sorry? As in fewer scripts trying to be clever?

put it where its required i.e. the bulk.sh file instead of adding it to the main script.

Yeah that makes sense. It works fine in bulk.sh.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request xbps-src xbps-src related
Projects
None yet
Development

No branches or pull requests

4 participants