On Fri, Mar 23, 2018 at 4:42 AM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > On Thu, Mar 22, 2018 at 10:29:27PM -0500, Eric Sandeen wrote: >> >> >> On 3/22/18 10:25 PM, Darrick J. Wong wrote: >> >> It make sense to check that it's available before running it, but I think >> >> hardcoding paths runs the risk of missing it if it's somewhere unique. >> >> > OTOH hardcoding the path (since we control where xfs_repair gets >> > installed) means that we avoid the "someone poisoned PATH" attack. I'm >> > not sure I buy that argument since if you have root access you probably >> > can just bind mount a garbage atop /sbin/xfs_repair, but eh. >> >> But this is the initramfs, right? Do we really have any idea where things >> land? Do initramfs paths follow the installed system paths? (maybe?) > > They land wherever the initramfs construction script puts them, though > at least on Debian the binaries are usually put in the same places as > they are on the rootfs. Not sure about dracut. :) > AFAICT in the few cases I saw (Debian based distros, Fedora, Arch), the paths were always the same on the rootfs and initramfs. But yeah, I agree that it's better to avoid hardcoding. I didn't know about "command -v", and "which" is not usually present, so I went with hardcoding rather than implement it on my own. Which is no issue now... Jan -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
