Unexpected behavior of 'DownloadUser' configration in pacman.conf.

NuSkool · 2024-09-20 00:25:35

I'm trying to find an answer to the following question from my other post. https://bbs.archlinux.org/viewtopic.php?id=299480
I had commented out 'DownloadUser' in pacman.conf.

3) Since I didn't uncomment 'DisableSandbox', it's still in use but using my $USER:$USER rather than alpm:alpm?

Am I misinterpreting the following info from man pacman.conf?

`man pacman.conf`

DownloadUser = username
Specifies the user to switch to for downloading files. If this config option is not set then the downloads are done as the user
running pacman.

I'd consider 'not set' in this context as either commented out or left blank. It does seems the man page is inaccurate or pacman is not working as intended, based on the test results.

I took into consideration the AUR package was in the cache on the first tests, so pacman was not actually downloading anything. I then performed additional testing on an official package into empty pacman cache.

I expeced pacman to use my user as 'user running pacman' for sandboxing as 'DownloadUser' when commenting out the setting.

It's possible the testing procedure may not properly/accurately represent my expected results. ie: wrong test, wrong search term, or I'm not reading the results right.

Based on the test results and additional testing, it seems commenting out 'DownloadUser' may disable sandboxing rather than using 'user running pacman'.

A test as user jeff in a VM running 'sudo pacman -S --debug webfs' with various configs for 'DownloadUser' and 'DisableSandbox' in pacman.conf.
The test is installing an AUR pkg from a local pacman repo. Output was searched for the term, 'sandbox'.

DownloadUser = alpm
# DisableSandbox
debug: config: sandboxuser: alpm
debug: option 'sandboxuser' = alpm

# DownloadUser = alpm
# DisableSandbox
debug: option 'sandboxuser' = (null)

DownloadUser = alpm
DisableSandbox
debug: config: sandboxuser: alpm
debug: option 'sandboxuser' = alpm

DownloadUser =
# DisableSandbox
debug: config: sandboxuser:
debug: option 'sandboxuser' =
error: failed to commit transaction (unexpected error)

DownloadUser = jeff
# DisableSandbox
debug: config: sandboxuser: jeff
debug: option 'sandboxuser' = jeff

DownloadUser = root
# DisableSandbox
debug: config: sandboxuser: root
debug: option 'sandboxuser' = root

DownloadUser = foo
# DisableSandbox
debug: config: sandboxuser: foo
debug: option 'sandboxuser' = foo
error: failed to commit transaction (unexpected error)

A test as user jeff in a VM running 'sudo pacman -S --debug ed' with various configs for 'DownloadUser' in pacman.conf.
The test is installing an official package, ed into an empty pacman cache. Output was searched for the term, 'sandbox'.

DownloadUser = alpm
# DisableSandbox
debug: config: sandboxuser: alpm
debug: option 'sandboxuser' = alpm

# DownloadUser = alpm
# DisableSandbox
debug: option 'sandboxuser' = (null)

DownloadUser =
# DisableSandbox
debug: config: sandboxuser:
debug: option 'sandboxuser' = 
error: failed to commit transaction (unexpected error)
Errors occurred, no packages were upgraded.

DownloadUser = jeff
# DisableSandbox
debug: config: sandboxuser: jeff
debug: option 'sandboxuser' = jeff

Allan · 2024-09-20 00:27:48

Are you running pacman as your user or root?

NuSkool · 2024-09-20 00:30:06

Running as user using sudo.

Scimmia · 2024-09-20 01:06:18

And what, exactly, do you think sudo does?

NuSkool · 2024-09-20 01:31:04

$ sudo echo "$USER"
jeff

I have no idea.

Are you implying pacman can download packages without elevated privileges? I'm not aware how to do it if it's possible.

Last edited by NuSkool (2024-09-20 01:35:46)

Scimmia · 2024-09-20 02:01:12

Checking an env variable doesn't mean much. The entire point of sudo is to execute a command as a different user, root by default.

As far as downloading without 'elevated privileges', that's the entire point of DownloadUser.

NuSkool · 2024-09-20 02:15:18

The point of the 'sudo $USER' was to illustrate that when you're using sudo, that wouldn't make it impossible to detect the who the user is.

I thought the point of sudo was to temporarily elevate privileges for non root users. I just log in as root when I need it.

$ pacman -Sw ed
error: you cannot perform this operation unless you are root.

Lol I'm not sure what you're actually getting at.
So I must be missing something then?
Please do share...

Last edited by NuSkool (2024-09-20 02:24:56)

seth · 2024-09-20 07:48:00

The point of the 'sudo $USER' was to illustrate that when you're using sudo, that wouldn't make it impossible to detect the who the user is.

That very much depends on the sudo configuration and is incredibly stupid and you're not demonstrating that at all:

FOO=bar sudo echo $FOO
sudo FOO=bar echo $FOO
sudo env FOO=bar echo $FOO
env FOO=bar echo $FOO
FOO=bar echo $FOO
FOO=bar; echo $FOO #  aha!
sudo echo $FOO # aha!
sudo FOO=papasmurf echo $FOO # wtf?

What resolves $FOO when?

id -u
id -ur
sudo id -u
sudo id -ur

Edit: for completeness sake, sudo does actually preserve the invoking UID,

sudo printenv

but that, again, configuration and also not portable (pkexec, doas - no, run0 is still not meant for privilege escalation) and is still stupid and dangerous, because

sudo SUDO_USER=papasmurf printenv

Last edited by seth (2024-09-20 07:54:48)

NuSkool · 2024-09-20 19:13:27

Ok thanks for the replies and I think I get it now. Took me a while with all the questions rather than an answer as I'm a little bit retarded with a splash of asperger's and OCD.

My original post here had a paragraph about how sudo or "privilege escalation" could possibly effect this, but I deleted it before posting, thinking I was going too far down the already deep rabbit hole I'm in trying to figure this stuff out.

I think I'll look into editing my installed version of the pacman man page to read as follows so it's more straightforward to me, as a (above description) and non programmer. Wouldn't this cover nearly all common use cases?

DownloadUser = username
Specifies the user to switch to for downloading files. If this config option is not set then the downloads are done as root. the user
running pacman.

Would it be accurate to say, if a user permanently assigned to his $USER account, admin permission or other permanent privileges allowing them to user use 'pacman -S' without needing to add "privilege escalation"* on the CLI, that this is the corner case that would cover the wording in the man page, or are there others?

* I'm aware that sudo can be configured to not have to type 'sudo' or a password for a command and I'm pretty sure other options exist. For this question lets not consider them.

In a normal user environment, where additional CLI "privilege escalation" is required to run 'pacman -S', is the sandboxing doing anything more secure than what pacman did before 7.0 if 'DownloadUser = alpm' is commented out in pacman.conf? How would this compare to just uncommenting 'DisableSandbox'? Would it be the same, different?

That said, since I still haven't got an actual answer to my original question, I'll attempt to answer it for myself, hopefully with confirmation (which hasn't been going well).

I had commented out 'DownloadUser' in pacman.conf.
3) Since I didn't uncomment 'DisableSandbox', it's still in use but using my $USER:$USER rather than alpm:alpm?

Answer: No that's incorrect in the majority of cases. The user would be considered root with the "privilege escalation" required on the CLI unless the users account had root equivalent privileges to begin with.

Last edited by NuSkool (2024-09-20 19:35:34)

seth · 2024-09-20 19:36:38

I'm aware that sudo can be configured to not have to type 'sudo'

How? I can't. You can suid binaries, but that's something entirely different.

"pacman -S foo" seems to check the UID and then immediately errors, so Allan might have to correct that, but I don't think there's any other accepted capability condition - you have to run it as UID 0.

is the sandboxing doing anything more secure than what pacman did before 7.0 if 'DisableSandbox' is commented out in pacman.conf? How would this compare to just uncommenting 'DisableSandbox'?

You mean "what's the point of the sanbox when the sandbox user is the root"?
I cannot say whether pacman still applies changes, but the root can escape every sandbox he's put into rather easily.
So the security is at best the one provided by barrier tape - yes, it's there and it will stop peoeple from strolling in, but it's not gonna stop anyone who wants to cross it.

NuSkool · 2024-09-20 19:45:48

Thanks seth!

Sorry, I edited my post after seeing an error. I thought it was before your reply but maybe not. Anyway the question makes a bit more sense now. Note: 'DownloadUser = alpm'

is the sandboxing doing anything more secure than what pacman did before 7.0 if 'DownloadUser = alpm' is commented out in pacman.conf? How would this compare to just uncommenting 'DisableSandbox'?

NuSkool · 2024-09-20 21:06:57

How?

I've never actually set up a command requiring a password to not need to type sudo or password on the CLI.
I've thought it would be possible in the past though, so made a working example.

I'll use a command I already have set up in an /etc/sudoers.d/ file I use for a script.

The command I'll used is 'pacsync aur'. I created a bash alias: alias psa='sudo pacsync aur'

This could very well be a one off, luck, or works for some unrelated reason I'm not aware of.
Also not advocating this or saying it's correct. Just posting how I did it with results.

I'll add that I ran the last command in a newly opened terminal with the results shown, due to sudo hanging on from the su command.

Test results:

[jeff@Arch2024p8 ~]$ type -P pacsync
/usr/bin/pacsync

[jeff@Arch2024p8 ~]$ alias | grep psa
alias psa='sudo pacsync aur'

[jeff@Arch2024p8 ~]$ pacsync aur
error: could not sync dbs (unexpected error)

[jeff@Arch2024p8 ~]$ sudo pacsync aur
aur.db is up to date

[jeff@Arch2024p8 ~]$ su
Password: 
[root@Arch2024p8 jeff]# pacsync aur
aur.db is up to date

Open a new terminal:

[jeff@Arch2024p8 ~]$ psa
aur.db is up to date

Last edited by NuSkool (2024-09-20 21:20:20)

seth · 2024-09-20 21:27:19

The command I'll used is 'pacsync aur'. I created a bash alias: alias psa='sudo pacsync aur'

That's not "sudo can be configured to not have to type 'sudo'" but an alias and a feature of your shell and you can alias anything to everything all the time, here's a silly one

alias greek="sed 'y/abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ/αβcδεφγηιθκλμνοπχρστυvωξψζΑΒCΔΕΦΓΗΙΘΚΛΜΝΟΠΧΡΣΤΥVΩΞΨΖ/'"

Ιτ αλλοωσ με το ποστ τηισ κινδ οφ νονσενσε.

(inb4 anyone mentions tr, you might wanna try first )

NuSkool · 2024-09-21 06:57:02

Ι σομεηοω μαναγε το ποστ νονσενσε νεαρλψ εvερψ τιμε, βυτ νεvερ ιντεντιοναλλψ

Your alias.... brings back memories from a decade ago when I figured out how to decode the pacman elephant. IIRC I was able to print either version with a much reduced size code.

Last edited by NuSkool (2024-09-21 07:03:30)

NuSkool · 2024-09-21 17:00:29

Back on subject,

My example of using '$USER' above was obviously wrong. I didn't take the time to look up the actual variable I was thinking of/had worked with in the past, and used it more for the concept.

In shell scripting, I've used 'getent' to get the user name*. I've also used 'id' to get user info, for example to create an nspawn containers with specific user uid:gid.** That in mind, wouldn't there be similar concepts available in C to safely to get the user name?

It's been mentioned that pacman checks for 'UID 0'. Couldn't C be safely used to take that one step further to obtain the actual user UID to assign as 'DownloadUser'?

Lack of portability has already been mentioned though, so perhaps that would be the biggest road block?

* (I'd use 'cut -d: -f1' if I wrote it today)

UZR=$(getent passwd 1000 | awk -F':' '{print $1}')

**

hostUID="$(id -u ${USER})"
hostGID="$(id -g ${USER})"

sudo systemd-nspawn -a -q groupadd -g "${hostGID}" builduser
sudo systemd-nspawn -a -q useradd -u "${hostUID}" -g "${hostGID}" -m -G wheel -s /bin/bash builduser

Disclaimer: Please excuse my general ignorance or lack of common sense, proper programming etiquette, using improper terminology, calling stuff by the wrong name, giving bad examples, and anything else that's dumb or dangerous... What may be common sense to a programmer or more knowledgeable person in the subject we're discussing may be completely unknown by me. I have absolutely no formal training or education in any of this stuff. I've never personally talked to anyone who would know what shell scripting is. I'm not willfully trying to provoke anyone or stir the pot by bringing up my findings, concepts, or trying to express ideas I have. I'm just genuinely interested and curious about this stuff and poor in communication skills. I'm a retired old man that enjoys Linux and shell, as a hobby. I narrowly investigate stuff that interests me at the moment. I commonly forget details, but often maintain a vague recollection of the general concepts. I keep notes on stuff I work on that are very poorly organized using symlinks.
I tend to get stuff working in shell (likely poorly executed) for myself. If my script successfully performs a task a few times without error, its good to me, till an error surfaces.

Last edited by NuSkool (2024-09-21 17:04:58)

Scimmia · 2024-09-21 17:44:12

What are you actually trying to accomplish here?

seth · 2024-09-21 21:04:50

It's been mentioned that pacman checks for 'UID 0'. Couldn't C be safely used to take that one step further to obtain the actual user UID to assign as 'DownloadUser'?

pacman checks the euid, the rest (error if it's not 0) was speculation on my part. And that does still not tell you whether or from what user you might have moved to UID0.

There's no reliable way to figure that (or if at all) in pacman, but there's also absolutely nothing preventing you from writing a local script in /usr/local/Syu, adding that NOPASSWD to the sudoers and have it check for the SUDO_UID and alter the DownloadUser (though since there seems no command switch, you'd have to generate a config on the fly and pass that to pacman)

That being said:

Scimmia wrote:

WTF?

NuSkool · 2024-09-25 21:37:18

The disclaimer was an attempt to convey where I'm coming from in case of any misunderstanding of my motivation.

Thanks for the feedback. I'd like to:

See if I can wrap pacman so it works for my initial interpretation* of the man page. wip
* If this config option is not set then the downloads are done as the **user typing on CLI** running pacman.

Learn some more about how things work under the hood.

See if I can figure out how to take advantage of the pacman sandbox features in an nspawn container and look into devtools to see if/how they use this.

See if I can wrap pacman so it works for my initial interpretation...

Here's a test script of a pacman wrapper, proof of concept for the DownloadUser defaulting to 'user typing on CLI', when unset.
However, it likely breaks more than it fixes, and requires not using sudo with 'pacman -S' until prompted.
I've also played around a bit with a user setup with 'UID 0' for gathering info/learning. (Yea I know, nonsense setup).
IMHO having pacman use the "person typing commands" as user for DownloadUser is something that'd require far more than my skills and bash to do right.

#alias sudo="sudo ${@}"
alias pacman='/home/jeff/bin/pacman-fix'

I gave up on the sudo alias...

#!/bin/bash

set -eu

	rm -f /tmp/tmp-pacman.conf

if	[[ ${*} == *-S* ]]; then

dlu=$(grep "DownloadUser" /etc/pacman.conf)

	if	[[ ${dlu} == '#'* ]]; then
		cp /etc/pacman.conf /tmp/tmp-pacman.conf
		sed -i "/ParallelDownloads/a DownloadUser = $(id -un $UID)" /tmp/tmp-pacman.conf

		if	[[ -s /tmp/tmp-pacman.conf ]]; then
			sudo pacman --config /tmp/tmp-pacman.conf "${@}"
		    else
			sudo pacman "${@}"
		fi

	    else
		sudo pacman "${@}"
	fi

    else
	pacman "${@}"
fi

See: 'sandboxuser' in debug output.

Ran with DownloadUser commented (unset) in pacman.conf: # DownloadUser = alpm

$ pacman -Sw --debug ed |& grep 'sandbox'
[sudo] password for jeff: 
debug: config: sandboxuser: jeff
debug: option 'sandboxuser' = jeff

Ran with DownloadUser uncommented (set) in pacman.conf: DownloadUser = alpm

$ pacman -Sw --debug ed |& grep 'sandbox'
[sudo] password for jeff: 
debug: config: sandboxuser: alpm
debug: option 'sandboxuser' = alpm

That said, are there any situations where a user other than 'DownloadUser = alpm' may be wanted/needed?
Seems having this setting baked into pacman indicates possible future applications?
Otherwise, what's the point of it if ~~uncommenting~~ commenting it out has the same effect as '--disable-sandbox'?

https://www.mail-archive.com/pacman-dev … 01132.html

Add DownloadUser configuration option
The DownloadUser option will be used to drop privledges to the
specified user when downloading files.
The intention is for this to be extended in the future to a more
general sandbox configuration to cover operating on package and
database files prior to verification.

And on my question of:

...look into devtools to see if/how they use this.

Built a fresh devtools nspawn container via manually deleting existing, then using 'pkgctl build'.
Initially looks like they're not using DownloadUser yet, although the scripts could be using an alternative pacman.conf.
Needs deeper investigation...

$ grep -Ei 'ParallelDownloads|DownloadUser' /etc/pacman.conf
ParallelDownloads = 5
DownloadUser = alpm

$ grep -Ei 'ParallelDownloads|DownloadUser' /var/lib/archbuild/extra-x86_64/jeff-1/etc/pacman.conf
ParallelDownloads = 5

$ grep -Ei 'ParallelDownloads|DownloadUser' /var/lib/archbuild/extra-x86_64/root/etc/pacman.conf
ParallelDownloads = 5

Looks like devtools doesn't ship with a custom pacman.conf...
I'll have to find where the generated pacman.conf is edited in the scripts.

paccat devtools -- pacman.conf

EDIT TO ADD INFO ON NSPAWN CONTAINERS:

To use pacman sandboxing in an nspawn container there are a few options.

Use '--system-call-filter=' on the CLI. ie:

 sudo systemd-nspawn --system-call-filter=@sandbox .....

Or setup a config file for regularly used containers as follows. See refs below for details on how to use it.
To use the config, you have to call it. ie: You could use '-M <cont-name>' or '--machine=<cont-name>' in your scripts.

/etc/systemd/nspawn/<cont-name>.nspawn

[Exec]
SystemCallFilter=@sandbox

References:
https://gitlab.archlinux.org/pacman/pacman/-/issues/195
https://wiki.archlinux.org/title/System … figuration
https://man.archlinux.org/man/systemd.nspawn.5

Last edited by NuSkool (2024-09-26 07:13:56)

Arch Linux

#1 2024-09-20 00:25:35

Unexpected behavior of 'DownloadUser' configration in pacman.conf.

#2 2024-09-20 00:27:48

Re: Unexpected behavior of 'DownloadUser' configration in pacman.conf.

#3 2024-09-20 00:30:06

Re: Unexpected behavior of 'DownloadUser' configration in pacman.conf.

#4 2024-09-20 01:06:18

Re: Unexpected behavior of 'DownloadUser' configration in pacman.conf.

#5 2024-09-20 01:31:04

Re: Unexpected behavior of 'DownloadUser' configration in pacman.conf.

#6 2024-09-20 02:01:12

Re: Unexpected behavior of 'DownloadUser' configration in pacman.conf.

#7 2024-09-20 02:15:18

Re: Unexpected behavior of 'DownloadUser' configration in pacman.conf.

#8 2024-09-20 07:48:00

Re: Unexpected behavior of 'DownloadUser' configration in pacman.conf.

#9 2024-09-20 19:13:27

Re: Unexpected behavior of 'DownloadUser' configration in pacman.conf.

#10 2024-09-20 19:36:38

Re: Unexpected behavior of 'DownloadUser' configration in pacman.conf.

#11 2024-09-20 19:45:48

Re: Unexpected behavior of 'DownloadUser' configration in pacman.conf.

#12 2024-09-20 21:06:57

Re: Unexpected behavior of 'DownloadUser' configration in pacman.conf.

#13 2024-09-20 21:27:19

Re: Unexpected behavior of 'DownloadUser' configration in pacman.conf.

#14 2024-09-21 06:57:02

Re: Unexpected behavior of 'DownloadUser' configration in pacman.conf.

#15 2024-09-21 17:00:29

Re: Unexpected behavior of 'DownloadUser' configration in pacman.conf.

#16 2024-09-21 17:44:12

Re: Unexpected behavior of 'DownloadUser' configration in pacman.conf.

#17 2024-09-21 21:04:50

Re: Unexpected behavior of 'DownloadUser' configration in pacman.conf.

#18 2024-09-25 21:37:18

Re: Unexpected behavior of 'DownloadUser' configration in pacman.conf.

Board footer