Unprivileged pacman?

EscapedNull · 2014-11-05 20:44:50

	/* check if we have sufficient permission for the requested operation */
	if(myuid > 0 && needs_root()) {
		pm_printf(ALPM_LOG_ERROR, _("you cannot perform this operation unless you are root.\n"));
		cleanup(EXIT_FAILURE);
	}

What is the purpose of this check, and is it technically required? The --root and --dbpath options allow an unprivileged user to specify a root and database path to which he has sufficient permissions. The check is a greater annoyance than security feature: one could use fakeroot or otherwise intercept the getuid(3) call, and pacman would end up relying on the operating system to enforce permissions (as it arguably should be doing in the first place). In case it was put there for convenience, a "Permission denied" error should be a dead giveaway to any Arch user.

There are plenty of reasons that unprivileged users might want to use pacman, such as to bootstrap an Arch system for use with some kind of chroot. Of course, it's easy to bypass this check using fakeroot, fakechroot, proot, etc., but this adds an additional step and no additional security. As an aside, pacstrap really does require root because it calls mount(1), but most of what pacstrap does can be done manually, or isn't necessary at all in some cases.

The obvious solution is to use sudo, like we've all been trained to do, but this unnecessarily exposes the host system to accidental and unintended modifications.

So, is there a reason behind pacman's root check? Am I missing something? Is it worth filing a bug report? Basically I'm just curious as to whether anyone else has had the same questions.

Stebalien · 2014-11-06 06:03:01

For one, this lets pacman fail early. Additionally, some install scripts probably expect to be run as root.

Lone_Wolf · 2014-11-06 12:05:30

EscapedNull wrote:

There are plenty of reasons that unprivileged users might want to use pacman, such as to bootstrap an Arch system for use with some kind of chroot.

I think you miss the most common reasons for using pacman as an unprivileged user :

Majority (maybe all of them) of the the -Q / --query options don't need root rights.

Same is true for pacman -Ss & pacman -Si options.

Have you looked at the needs_root() function ?
The code used there should give some clues about how useful that check is.

Trilby · 2014-11-06 12:14:08

I think the OPs point was that while there are times pacman would need to be root and times it doesn't it should need to check for this because it gets false positives: the needs_root function would return that it does need to be root even when it doesn't (in the cases of a chroot for example). Further there is nothing prevented by the needs_root function: if one does not have root access, the attempts to write to the filesystem root would fail. So it seems the claim is there are rare but possible false positives, while the correct detections serve no purpose. Under these conditions the check is not worthwhile.

I don't personally see anything wrong with this, but the OPs point seems logically valid to me. For an analogy consider the `mv` command. `mv` doesn't have a needs_root function. If you move files between places your user has access to it succeeds, if you try to move files to places you don't have access to, it fails. Nothing would be added by the inclusion of a needs_root check. So the question is not what feature does the needs_root implement, but rather what feature does it add that would not already be ensured by filesystem access rights.

progandy · 2014-11-06 13:52:41

Maybe pacman should require write permissions for RootDir, DBPath, CacheDir, GPGDir and LogFile instead of asking for root privileges. That might be a more logical solution for instances where pacman is used with a modified root dierctory. Pacman could still print a warning if it runs an installation without root privileges since that will remove all special file permissions set in a package and some installscripts might fail.

Edit: Still, if you run an installation without root in a directory you can write, there still might be some subdirectories where you are missing the proper permissions and pacman has to roll back all changes it has done. So pacman installations without root are simply not a good idea, and I don't see a problem with using fakeroot in those rare cases where you need it.

Last edited by progandy (2014-11-06 14:00:13)

EscapedNull · 2014-11-06 22:02:42

Lone_Wolf wrote:

Majority (maybe all of them) of the the -Q / --query options don't need root rights.

Sorry, I wasn't specific enough. I was referring to those which do fall into the needs_root() category. -S, -R, -D, to name a few.

Trilby wrote:

I think the OPs point was that while there are times pacman would need to be root and times it doesn't it should need to check for this because it gets false positives: the needs_root function would return that it does need to be root even when it doesn't (in the cases of a chroot for example). Further there is nothing prevented by the needs_root function: if one does not have root access, the attempts to write to the filesystem root would fail. So it seems the claim is there are rare but possible false positives, while the correct detections serve no purpose. Under these conditions the check is not worthwhile.
I don't personally see anything wrong with this, but the OPs point seems logically valid to me. For an analogy consider the `mv` command. `mv` doesn't have a needs_root function. If you move files between places your user has access to it succeeds, if you try to move files to places you don't have access to, it fails. Nothing would be added by the inclusion of a needs_root check. So the question is not what feature does the needs_root implement, but rather what feature does it add that would not already be ensured by filesystem access rights.

Right on point. That's what I meant by "pacman would end up relying on the operating system to enforce permissions." Instead of trying to guess at whether an EACCES will be returned (based on uid), why not handle the error and print the message when (and if) the error is encountered? For the purpose of illustration, what do you think would happen if I compiled my own pacman, that didn't perform the root check?

Failing early is a condition that I hadn't thought of, however pacman seems pretty good about cleaning up after itself in the event of errors, so as not to leave the database nor filesystem in an inconsistent state. It's not perfect, but it does try to handle consistency using transactions. Nevertheless, an EACCES ("Permission denied") error is not vastly different from any other error (I/O errors, power failures, kernel panics, ...) from pacman's perspective on consistency.

I agree that this is an edge case that most users will not encounter, but I don't see that as a reason to ignore it, either. For the record, the solution that worked for me was (approximately):

$ cp -R /var/lib/pacman/local newroot/var/lib/pacman
$ cp -R /var/cache/pacman/pkg newroot/var/cache/pacman #optional, avoids downloading package files
$ fakechroot -s fakeroot -- pacman -r newroot/ -S base

progandy wrote:

Maybe pacman should require write permissions for RootDir, DBPath, CacheDir, GPGDir and LogFile instead of asking for root privileges. That might be a more logical solution for instances where pacman is used with a modified root dierctory. Pacman could still print a warning if it runs an installation without root privileges since that will remove all special file permissions set in a package and some installscripts might fail.

Checking for write permissions and issuing a non-root warning sounds like a good compromise.

progandy wrote:

Edit: Still, if you run an installation without root in a directory you can write, there still might be some subdirectories where you are missing the proper permissions and pacman has to roll back all changes it has done. So pacman installations without root are simply not a good idea, and I don't see a problem with using fakeroot in those rare cases where you need it.

fakeroot temporarily deceives pacman into thinking that the permissions are okay (as pacman specified them), however permissions can be a problem after fakeroot terminates. 'pacman -Qkk' will reveal those problems. Nevertheless, I've never (yet) run into a case where this actually caused any major issues. Root filesystems I've created this way have run just fine under chroot, fakeroot, proot, and even systemd-nspawn, to name a few.

Arch Linux

#1 2014-11-05 20:44:50

Unprivileged pacman?

#2 2014-11-06 06:03:01

Re: Unprivileged pacman?

#3 2014-11-06 12:05:30

Re: Unprivileged pacman?

#4 2014-11-06 12:14:08

Re: Unprivileged pacman?

#5 2014-11-06 13:52:41

Re: Unprivileged pacman?

#6 2014-11-06 22:02:42

Re: Unprivileged pacman?

Board footer