Re: [PATCH 1/7] dpkg-raw: Respect file permissions defined by recipe

[Henning Schild <henning.schild@siemens.com>]

Am Mon, 7 Jan 2019 17:54:26 +0100
schrieb Jan Kiszka <jan.kiszka@siemens.com>:

> On 07.01.19 17:28, Henning Schild wrote:
> > Am Mon, 7 Jan 2019 15:26:16 +0100
> > schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> >   
> >> On 07.01.19 15:20, Jan Kiszka wrote:  
> >>> On 07.01.19 15:19, Henning Schild wrote:  
> >>>> Am Mon, 7 Jan 2019 14:28:47 +0100
> >>>> schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> >>>>     
> >>>>> On 07.01.19 14:20, Henning Schild wrote:  
> >>>>>> Am Wed, 2 Jan 2019 12:34:11 +0100
> >>>>>> schrieb Jan Kiszka <jan.kiszka@siemens.com>:  
> >>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>>>>
> >>>>>>> dh_fixperms overwrites the permissions do_install defined
> >>>>>>> carefully. Skip this step to avoid that.
> >>>>>>>
> >>>>>>> Fixes: f301ccb2b5b1 ("meta/dpkg-raw: build raw packages like
> >>>>>>> all others") CC: Henning Schild <henning.schild@siemens.com>
> >>>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>>>> ---
> >>>>>>>     meta/classes/dpkg-raw.bbclass | 4 +++-
> >>>>>>>     1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>>>>
> >>>>>>> diff --git a/meta/classes/dpkg-raw.bbclass
> >>>>>>> b/meta/classes/dpkg-raw.bbclass index 8d11433..10fb1b9 100644
> >>>>>>> --- a/meta/classes/dpkg-raw.bbclass
> >>>>>>> +++ b/meta/classes/dpkg-raw.bbclass
> >>>>>>> @@ -56,9 +56,11 @@ EOF
> >>>>>>>     deb_create_rules() {
> >>>>>>>         cat << EOF > ${S}/debian/rules
> >>>>>>>     #!/usr/bin/make -f
> >>>>>>> +
> >>>>>>> +override_dh_fixperms:
> >>>>>>> +
> >>>>>>>     %:
> >>>>>>>         dh \$@
> >>>>>>> -  
> >>>>>>
> >>>>>> I think it is not a good idea to do that in general. While you
> >>>>>> might have found an example where dh_fixperms caused problems,
> >>>>>> there are probably many where it helps. Say people use "cp" to
> >>>>>> fill ${D} or "echo" to fill ${D}/bin/  
> >>>>>
> >>>>> I'm open for better suggestions.  
> >>>>
> >>>> The suggestion is to do that in the one recipe that you need it
> >>>> for, and not touch the general case.  
> >>>
> >>> ...except for causing that regression: Keep in mind that we used
> >>> to respect permissions defined by the user before the switch to
> >>> packaging via Debian!  
> > 
> > True, but there is a changelog section that even tells users how to
> > disable certain dhs for their recipes.
> >   
> >> To make my issue more concrete: Consider you want to package
> >> secrets this way. Then it would be rather ugly to even temporary
> >> have them group or even work readable during packaging and
> >> installation - in case you suggestion should be to adjust the
> >> permissions in a postinst.  
> > 
> > Having secrets in your repo and build process would be ugly as well,
> > many spots where they could leak. So i do not think that is a good
> > example.
> > And i am not talking about a postinst, but a rules file that does
> > exactly what yours does. See what example-raw does for dh_usrlocal,
> > if you bring your rules you do not get the defaults.
> > Looking at the man-page i see a lot of "removes permission", where
> > documentation seems to be the only exception. Again secret does not
> > seem to be a good example. (except you place it in
> > usr/share/doc ;) )
> > 
> > What exactly is your motivation for the change?  
> 
> Allow to ship files that are not world-readable by defaults. That's a
> pretty common pattern, e.g. to add pre-generated keys, certificates,
> wifi passwords etc.

I think i got that but i am not sure how they would become world
readable, not from the man-page nor from the code. Except you got the
location "wrong". So a full path example with the permissions before
and after is what i was asking for.

Henning

> So I don't think it is a good idea that dpkg-raw now breaks this use
> case, sometimes silently(!), and forces users to overload their rules
> files. I'm not even sure that it makes sense for Debian to add these
> permissions to during the fixperms phase, but I didn't dig into that
> details.
> 
> Jan
>