Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #51692 > unrolled thread

Bug#767448: No way to override settings from /usr/share/initramfs-tools/conf-hooks.d/*

Started byBen Hutchings <ben@decadent.org.uk>
First post2015-12-11 03:50 +0100
Last post2016-04-17 03:00 +0200
Articles 5 — 3 participants

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#767448: No way to override settings from /usr/share/initramfs-tools/conf-hooks.d/* Ben Hutchings <ben@decadent.org.uk> - 2015-12-11 03:50 +0100
    Bug#767448: No way to override settings from /usr/share/initramfs-tools/conf-hooks.d/* Ben Hutchings <ben@decadent.org.uk> - 2016-01-25 18:40 +0100
      Bug#767448: No way to override settings from /usr/share/initramfs-tools/conf-hooks.d/* Piotr Jurkiewicz <piotr.jerzy.jurkiewicz@gmail.com> - 2016-02-29 05:20 +0100
        Bug#767448: No way to override settings from /usr/share/initramfs-tools/conf-hooks.d/* Ben Hutchings <ben@decadent.org.uk> - 2016-04-17 03:00 +0200
          Processed: Re: No way to override settings from /usr/share/initramfs-tools/conf-hooks.d/* owner@bugs.debian.org (Debian Bug Tracking System) - 2016-04-17 03:00 +0200

#51692 — Bug#767448: No way to override settings from /usr/share/initramfs-tools/conf-hooks.d/*

FromBen Hutchings <ben@decadent.org.uk>
Date2015-12-11 03:50 +0100
SubjectBug#767448: No way to override settings from /usr/share/initramfs-tools/conf-hooks.d/*
Message-ID<qElWp-6r8-1@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

On Fri, 31 Oct 2014 06:17:46 +0100 Piotr Jurkiewicz <piotr.jerzy.jurkiewicz@gmail.com> wrote:
> Package: initramfs-tools
> 
> There is no way for user to override settings from 
> /usr/share/initramfs-tools/conf-hooks.d.
> 
> For example, dropbear package in file /usr/.../conf-hooks.d/dropbear 
> sets UMASK variable to 0077. User cannot override this with his own 
> setting in /etc.
> 
> The only way to do that is to edit /usr/.../conf-hooks.d/dropbear file 
> directly and change UMASK. However, such change will be of course 
> overwritten on a next update of dropbear package.

Actually, you can use dpkg-divert to rename this file to somewhere else
that initramfs-tools will ignore it.  dpkg will follow that renaming so
it won't undo your change.

> In my opinion, user-provided settings from /etc/* should have priority 
> over package-provided settings form /usr/*.

This is a tricky one.  Some packages really do need to override
initramfs.conf, to enable features they depend on.  I agree we need to
come up with a better approach for controlling the UMASK variable.

Ben.

-- 
Ben Hutchings
One of the nice things about standards is that there are so many of them.

[toc] | [next] | [standalone]

#52436

FromBen Hutchings <ben@decadent.org.uk>
Date2016-01-25 18:40 +0100
Message-ID<qUTho-7r7-17@gated-at.bofh.it>
In reply to#51692

[Multipart message — attachments visible in raw view] — view raw

Control: tag -1 moreinfo

On Fri, 2015-12-11 at 02:43 +0000, Ben Hutchings wrote:
> On Fri, 31 Oct 2014 06:17:46 +0100 Piotr Jurkiewicz  wrote:
> > Package: initramfs-tools
> >  
> > There is no way for user to override settings from 
> > /usr/share/initramfs-tools/conf-hooks.d.
> >  
> > For example, dropbear package in file /usr/.../conf-hooks.d/dropbear 
> > sets UMASK variable to 0077. User cannot override this with his own 
> > setting in /etc.
> >  
> > The only way to do that is to edit /usr/.../conf-hooks.d/dropbear file 
> > directly and change UMASK. However, such change will be of course 
> > overwritten on a next update of dropbear package.
> 
> Actually, you can use dpkg-divert to rename this file to somewhere else
> that initramfs-tools will ignore it.  dpkg will follow that renaming so
> it won't undo your change.
> 
> > In my opinion, user-provided settings from /etc/* should have priority 
> > over package-provided settings form /usr/*.
> 
> This is a tricky one.  Some packages really do need to override
> initramfs.conf, to enable features they depend on.  I agree we need to
> come up with a better approach for controlling the UMASK variable.

The UMASK variable is *documented* as affecting only the permissions
for the initramfs image (which it doesn't seem to do reliably!) but it
also affects the permissions for the files inside the initramfs.

When dropbear is used in the initramfs, the host private key must be
kept secret and so the initramfs image must not be world-readable.  But
most of the files installed in the initramfs can be world-readable.  Is
that what you want to change?

I don't think we can simply 'fix' the behaviour of UMASK now, because
other packages may depend on it.  I think that the proper fix may
require introducing a new configuration variable, e.g. 'SECRET' that
really only affects the permissions of the initramfs image.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
                                    A fail-safe circuit will destroy others.

[toc] | [prev] | [next] | [standalone]

#53080

FromPiotr Jurkiewicz <piotr.jerzy.jurkiewicz@gmail.com>
Date2016-02-29 05:20 +0100
Message-ID<r7ntn-5bT-1@gated-at.bofh.it>
In reply to#52436
> The UMASK variable is *documented* as affecting only the permissions
> for the initramfs image (which it doesn't seem to do reliably!) but it
> also affects the permissions for the files inside the initramfs.
 >
> When dropbear is used in the initramfs, the host private key must be
> kept secret and so the initramfs image must not be world-readable.  But
> most of the files installed in the initramfs can be world-readable.  Is
> that what you want to change?

No. I wasn't even aware that UMASK also affects the permission of files 
inside initramfs (as this is undocumented, as you said).

My setup is the following: Machine A with Debian boots from the network. 
Its /boot directory resides on machine B, which is simply a PXE server 
for machine A. /boot directory is mounted on machine A using sshfs. That 
way, on each update of machine A, kernel image and initramfs file are 
automatically transferred to machine B.

The problem is that tftpd on machine B has compiled-in limitation which 
allows only publicly readable files (o+r) to be served via TFTP.

Because dropbear package sets UMASK variable to 0077, (re)created 
initramfs file has no o+r permission. That means that it cannot be 
served by tftpd. So basically machine A won't boot on next reboot after 
update.

That's why I must override UMASK for (re)created initramfs.

Another solution for my problem would be to retain permission of 
existing initramfs file during initramfs regeneration and use UMASK only 
when initramfs file does not exist.

[toc] | [prev] | [next] | [standalone]

#53643

FromBen Hutchings <ben@decadent.org.uk>
Date2016-04-17 03:00 +0200
Message-ID<roJea-3Rv-1@gated-at.bofh.it>
In reply to#53080

[Multipart message — attachments visible in raw view] — view raw

Control: retitle -1 Configuration files can't override UMASK value set by packages
Control: tag -1 wontfix

On Mon, 29 Feb 2016 05:13:33 +0100 Piotr Jurkiewicz <piotr.jerzy.jurkiewicz@gmail.com> wrote:
> > The UMASK variable is *documented* as affecting only the permissions
> > for the initramfs image (which it doesn't seem to do reliably!) but it
> > also affects the permissions for the files inside the initramfs.
>  >
> > When dropbear is used in the initramfs, the host private key must be
> > kept secret and so the initramfs image must not be world-readable.  But
> > most of the files installed in the initramfs can be world-readable.  Is
> > that what you want to change?
> 
> No. I wasn't even aware that UMASK also affects the permission of files 
> inside initramfs (as this is undocumented, as you said).
> 
> My setup is the following: Machine A with Debian boots from the network. 
> Its /boot directory resides on machine B, which is simply a PXE server 
> for machine A. /boot directory is mounted on machine A using sshfs. That 
> way, on each update of machine A, kernel image and initramfs file are 
> automatically transferred to machine B.
> 
> The problem is that tftpd on machine B has compiled-in limitation which 
> allows only publicly readable files (o+r) to be served via TFTP.
[...]

That makes sense, because everyone on the network can read any file
exposed over TFTP.  You're asking us to help you maintain a security
hole, and I refuse to do that.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.

[toc] | [prev] | [next] | [standalone]

#53644 — Processed: Re: No way to override settings from /usr/share/initramfs-tools/conf-hooks.d/*

Fromowner@bugs.debian.org (Debian Bug Tracking System)
Date2016-04-17 03:00 +0200
SubjectProcessed: Re: No way to override settings from /usr/share/initramfs-tools/conf-hooks.d/*
Message-ID<roJea-3Rv-5@gated-at.bofh.it>
In reply to#53643
Processing control commands:

> retitle -1 Configuration files can't override UMASK value set by packages
Bug #767448 [initramfs-tools] No way to override settings from /usr/share/initramfs-tools/conf-hooks.d/*
Changed Bug title to 'Configuration files can't override UMASK value set by packages' from 'No way to override settings from /usr/share/initramfs-tools/conf-hooks.d/*'.
> tag -1 wontfix
Bug #767448 [initramfs-tools] Configuration files can't override UMASK value set by packages
Added tag(s) wontfix.

-- 
767448: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767448
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web