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

NuSkool · Yesterday 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 · Yesterday 00:27:48

Are you running pacman as your user or root?

NuSkool · Yesterday 00:30:06

Running as user using sudo.

Scimmia · Yesterday 01:06:18

And what, exactly, do you think sudo does?

NuSkool · Yesterday 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 (Yesterday 01:35:46)

Scimmia · Yesterday 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 · Yesterday 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 (Yesterday 02:24:56)

seth · Yesterday 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 (Yesterday 07:54:48)

NuSkool · Yesterday 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 (Yesterday 19:35:34)

seth · Yesterday 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 · Yesterday 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 · Yesterday 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 (Yesterday 21:20:20)

seth · Yesterday 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 )

Arch Linux

#1 Yesterday 00:25:35

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

#2 Yesterday 00:27:48

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

#3 Yesterday 00:30:06

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

#4 Yesterday 01:06:18

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

#5 Yesterday 01:31:04

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

#6 Yesterday 02:01:12

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

#7 Yesterday 02:15:18

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

#8 Yesterday 07:48:00

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

#9 Yesterday 19:13:27

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

#10 Yesterday 19:36:38

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

#11 Yesterday 19:45:48

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

#12 Yesterday 21:06:57

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

#13 Yesterday 21:27:19

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

Board footer