Arch Linux

This bug will make any user able to dump crypto_keyfile.bin from initramfs image.

As far as I can tell, it has always been the case that the images were created with world readable bit set. Sure, one could use umask, and it probably wouldn't have impact on the booting process, since the early userspace ia a show ran by root.

The only use case where the issue you described would be an issue is on a server, where you have untrusted users with shell access (or being able to run commands).

The bug report specifically points out that the alpm hook, not mkinitcpio, deletes the file before rerunning /usr/bin/mkinitcpio, preventing mkinitcpio from using existing code that is intended to preserve existing permissions.

This is a problem because typically users embedding security material in the initramfs run chmod on the initramfs before or right after adding that security material by rerunning mkinitcpio with a modified config. And mkinitcpio itself respects that.

This didn't happen back when the initramfs was only removed during a "package* deletion, but the new hook fully deletes all vestiges of the initramfs every time /usr/lib/modules/$(uname -r)/ is deleted and replaced by a new directory with a different version.

You don't need to explain the hook I wrote to me. I think the images could probably always be 600, but that also begs the question if everything on /boot should as well. Currently the kernel and -ucode are 644. Anyway, I'll add this as an issue. From what I saw dracut writes the images with 600 as well.

Why are you saying that as though you think I've committed a personal attack?

I wasn't explaining it to you, I was examining it to "anyone reading this", for the sake of context.

Sue me, I guess, for being a wordy person.

I have no time for this passive-aggressive bs. *Every* opportunity you see to dig at the mkinitcpio hooks, you do. I'm going to change mkinitcpio's behavior on this because it makes sense to. I'm also wondering if the kernel image shouldn't be copied with 600 too.

So. When I mentioned this exact issue to you, what, over a year ago now on IRC? You told me what amounted to "you can go fly a kite" because I didn't both report the issue *and* provide a patch for it?

I guess that not providing a patch qualifies as passive-aggressive BS now. Because clearly if I don't also provide a patch every time I report an issue it constitutes a "dig" at your hooks.

I *strongly* recommend you look in the mirror. You have a bizarre, irrational hatred of seeing my name and the word "mkinitcpio" together, and you automatically assume malice aforethought every time it occurs.

It's tiresome and sickening. Please stop this. Expressing doubt about your code is not reasonable grounds for personal attacks.

There is a reason I haven't volunteered my copious spare time for writing mkinitcpio patches -- you've made it *agonizing* to think about doing so.

Is this what Arch has come to?

Doesn't matter who wrote the hook, this is a security issue and should be fixed.
If two of the senior devs in the Arch project act like this to each other, I can see why Arch gets the poor reputation for not only trying to get help, but the lashback when reporting bugs.
I love Arch Linux. I don't want to see this, ever.

I'll pitch in if I'm able. I just need to know where to push a PR now and then.

This ain't a security issue. The initramfs image was always written with 644 on mkinitcpio. Also, there's a long history going on here that you are unaware of. I'll fix this on the next mkinitcpio release, but if you want, you can send a PR to https://github.com/archlinux/mkinitcpio