[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#633582: initramfs-tools: All files in initrd owned by root



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/30/2014 11:31 AM, Michael Prokop wrote:
> [Adding Harald Hoyer from dracut to CC, maybe he can enlighten us about the
> reasoning in dracut. Harald, this is about 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633582 which I'm also
> quoting in the following mail ]
> 
> * Teddy Hogeborn [Thu Jan 30, 2014 at 10:35:56AM +0100]:
>> intrigeri <intrigeri@boum.org> writes:
>>> Michael Prokop wrote (23 Nov 2011 11:45:14 GMT) :
> 
>>>> maximilian: i've scheduled the patch for inclusion via 
>>>> mika/user_permissions.
> 
>>> Was this included eventually?
> 
>> No.
> 
>> We have, for two years now, a very ugly workaround in mandos-client to
>> deal with this.
> 
> Maks, please report back what's your opinion how to handle that.
> 
> FTR, that's what dracut uses (latest git as of today):
> 
> ,---- [ dracut.sh ] | if [[ $create_early_cpio = yes ]]; then |     echo 1
> > "$early_cpio_dir/d/early_cpio" |     # The microcode blob is _before_ the
> initramfs blob, not after |     (cd "$early_cpio_dir/d";     find . -print0
> | cpio --null -R 0:0 -H newc -o --quiet >../early.cpio) |     mv
> $early_cpio_dir/early.cpio $outfile.$$ | fi | if ! ( umask 077; cd
> "$initdir"; find . -print0 | cpio --null -R 0:0 -H newc -o --quiet | \ 
> `----
> 
> And see:
> 
> ,---- [ dracut.git % git show 8e5db363 ] | commit
> 8e5db363e8c14f2964fe71100f3dcd7f912ca283 | Author: Harald Hoyer
> <harald@redhat.com> | Date:   Fri Jan 24 15:27:15 2014 +0100 | |
> dracut.sh: set file owners of early cpio files to 0:0 | | diff --git
> a/dracut.sh b/dracut.sh | index 2142e2d..0970710 100755 | --- a/dracut.sh |
> +++ b/dracut.sh | @@ -1464,10 +1464,10 @@ rm -f -- "$outfile" |  dinfo "***
> Creating image file ***" |  if [[ $create_early_cpio = yes ]]; then |
> # The microcode blob is _before_ the initramfs blob, not after | -    (cd
> "$early_cpio_dir/d"; find . -print0 | cpio --null -o -H newc --quiet
> >../early.cpio) | +    (cd "$early_cpio_dir/d";     find . -print0 | cpio
> --null -R 0:0 -H newc -o --quiet >../early.cpio) |      mv
> $early_cpio_dir/early.cpio $outfile.$$ |  fi | -if ! ( umask 077; cd
> "$initdir"; find . -print0 | cpio --null -R 0:0 -H newc -o --quiet| \ | +if
> ! ( umask 077; cd "$initdir"; find . -print0 | cpio --null -R 0:0 -H newc
> -o --quiet | \ |      $compress >> "$outfile.$$"; ); then |      dfatal
> "dracut: creation of $outfile.$$ failed" |      exit 1 `----
> 
> So there might be a good reason why also dracut goes for all files in
> initrd owned by root. Harald, do you have any bug reports or details about
> why dracut decided to handle it this way that you might share with us?
> 
> regards, -mika-
> 

Initially it was done to prevent user (uid!=0) generated initramfs images to
accidentally produce static device nodes owned by that user.

But you are right, we should preserve the owners, if root builds the image.

So, here is the upstream commit for dracut:

http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=c8a9a6b4a7dff76c66e84f65b2717632e1bb4505

Thanks!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS6nGjAAoJEANOs3ABTfJwTsEP/1Xsq6A0v8oMrQOW1zMrcVq/
YOsp+qQxzEIE1xIMjm7aNYmuA5NMtlDLZL1wFrjqZ44P1oDyiDjmV6TdNcntZQAL
NLXjOk144A8FdLt+FMOdgu0cKo67JMo7uc7dRFSq57FKuvNOR1pKncybtN40q8w2
Gg+139bQGxbh5K1E4W5a01LxinyLK7EZMIdQR/+JCFoQsJoCwjXTJTzC8LTRmvc1
ZXT3CD5expvX9oSqpzvUCKqLp/5rC4Uxb7rzc0qq7jP4qMdAjObwUlBqdxrOLnn5
7FTCC19yVP9Xx6moLBpzjXti6Q3M9DPXdhnuLHf9VFOqlZF+dOZCDrQomjnzUG7L
1cICRD9k5mzZSHulviuAXElouVpaI4UgJJwkYz8Xj1uqxm8jHiT6dEly19DYSdrt
L84NzTnc/HJwVZ43+xFBti2iJy6auTXrMn+YrkF7x96Q0UST5qUe8lZdfi5fboHv
5KVbqhXJNRzes2tDMSbotN94obD0tHwhcXKe+14CXmheuoPrM2DfmDCOrpl2ntSh
epfCGJcUbb82Iock/WDvQuaGifG3oBGb1o7Erz+AQ72Hcy4y5yWywlNSD62NB/S3
OoFs1MDUmfN4iPcm1SSp2VvmKK9dZ2dEMQjGQ2x8qfzAy/4KpqbTu//CvmH6K2Nv
KBkUmYtC8jBabs1TZurT
=gZvp
-----END PGP SIGNATURE-----


Reply to: