Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#29162 - [mkinitcpio] Don't copy mount from $PATH

Attached to Project: Arch Linux
Opened by Ted Pavlic (tpavlic) - Thursday, 29 March 2012, 03:50 GMT
Last edited by Dave Reisner (falconindy) - Wednesday, 04 April 2012, 00:32 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Description: If a user with sudo access has a mount colorizer installed, mkinitcpio will not copy the mount binary into the initramfs. Instead, it will copy the colorizer wrapper.

This has never been a problem until a recent update of mkinitcpio.

Additional info:
* mkinitcpio 0.8.5-1
* AUR/cw installed, but applies to any colorizing mount wrapper

Steps to reproduce (on a user account):

1. Install AUR/cw (or similar colorizer that includes mount support)
2. Adjust PATH to place /usr/lib/cw (the location of the mount wrapper) before /bin
3. Run
sudo mkinitcpio -p linux

The result is that /usr/lib/cw/mount is copied into the initramfs instead of /bin/mount. Consequently, the next boot will fail.
This task depends upon

Closed by  Dave Reisner (falconindy)
Wednesday, 04 April 2012, 00:32 GMT
Reason for closing:  Implemented
Additional comments about closing:  mkinitcpio 0.8.6
Comment by Dave Reisner (falconindy) - Thursday, 29 March 2012, 03:57 GMT
yeah... mkinitcpio isn't the only thing that garbage like cw will break. I'm not keen on hardcoding paths just because an AUR package is breaking your build.
Comment by Dave Reisner (falconindy) - Thursday, 29 March 2012, 04:08 GMT
Additionally, the mkinitcpio version that "broke" this was 0.8.3, released a month ago.
Comment by Ted Pavlic (tpavlic) - Thursday, 29 March 2012, 04:32 GMT
A month sounds right. I'm forced to use Fedora at work, and so my Arch machine at home doesn't get turned on (let alone updated) every day. Moreover, mkinticpio doesn't run every update. When it did run, I thought the error had something to do with mkinitcpio-busybox, and I filed a bug there. It wasn't until it ran again (which happened recently) that I discovered /usr/lib/cw/mount was being used.

Hard-coding paths does not need to be the solution, does it? Can't there be a restricted and configurable PATH used by mkinitcpio? SSH uses a restricted path, and I view mkinitcpio much more important than SSH.

Alternatively, I suppose env_reset can be turned on in sudoers. I don't know if there is a way to confine env_reset just to specific commands (like pacman, yaourt, and mkinitcpio), but a blanket env_reset is the default on many other distributions, IIRC.
Comment by Dave Reisner (falconindy) - Thursday, 29 March 2012, 04:35 GMT
As per sudoers(5), env_reset is the default behavior. I'm considering hardcoding the PATH to the basic set of bins, but I need to review the current hooks to make sure that won't be problematic.
Comment by Ted Pavlic (tpavlic) - Thursday, 29 March 2012, 05:13 GMT
I know that sudoers(5) says that env_reset is by default, but that does not appear to be the case. I had to turn on env_reset explicitly in order to get the desired behavior. I also notice that other distributions (e.g., my Fedora machine at work) make env_reset explicit.

On your Arch system, if you do a "sudo env|grep PATH", what do you see? If the PATH was restricted by default, I would have never had the problem with mkinitcpio.