From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6641861376070385664 X-Received: by 2002:a1c:2088:: with SMTP id g130mr990030wmg.6.1546880068166; Mon, 07 Jan 2019 08:54:28 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:adf:e0d0:: with SMTP id e16ls219695wri.11.gmail; Mon, 07 Jan 2019 08:54:27 -0800 (PST) X-Google-Smtp-Source: ALg8bN4nQVTQjIuEqNfW/Z8z4Tvm4mfX2pBvN1dH9M+vDzMZZ3wS7JxxsUsM6Nl/Uma9mSVr6oCq X-Received: by 2002:adf:8245:: with SMTP id 63mr3164216wrb.25.1546880067636; Mon, 07 Jan 2019 08:54:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546880067; cv=none; d=google.com; s=arc-20160816; b=mjcYklAbiRJYw8Iu4RdDmHLLspbHYTaNMDmEDp4fiJTxFKFaa5RL1Wq4SUDPaUCJh7 NYZ4H7LQBSAWmUBGL6Mqmm+Rc+ojSwA1cs1dTAHJ9gDptwrnBHBWAnWqJ0PmMY8j2eOc sP1X77O32JeLbRTP82RbBT50avtr2cKAgjVk5VfVLIc2Bazjmt9NPMjaiQ8sMCRW2sLa p7nyZCaSr07gXFinZ8bzzX6CFXEbgcHyrOn0uHGmA00VGQIBDW0NCCwPbE3z1ThbIQm+ EZFsmKzyOsG1VurLYSBbLQfQypFPqH9WKIHyyWjW/Ec0GLK3heUd/JgC4Gfki9BmS25Z y8fQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject; bh=PCs437eYlyqTR/bXflu+9VSqwhGMcKH9kZwYdpIzM7Q=; b=JRjLlxuv6az4+98dFZbhX/ZyNz/NPfrJ+rO3Cm7sow2rDhhwtNi6KjPUvgxZbPNcfp qBDl0ZgR4fuAD5nFfpfKKF46eqS3Jjc+dfJYAl/6ys9o8lYjYfXQVkOyr8JTXnzpGFY+ /NL0jU0FTbsybvwYVggoTChJLYgqiv8nu1+R/cCkTpm3LW8d3YFyP62Zr8oc1pQQTcoO ly34Tz9BB391f32VMow9BGoLvkl14VfTQZGHzyAgLsd+hg9LwlxUfrPIowGrJqQaWU4h UshjsrLdAu9PzCjNbhsl1FTy15KmLGCqVqH1omDndRgKVBm48ydR5ON+nYBMWPj3Az0C IAbw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id f6si496217wmj.0.2019.01.07.08.54.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Jan 2019 08:54:27 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id x07GsRkb000983 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 7 Jan 2019 17:54:27 +0100 Received: from [167.87.32.100] ([167.87.32.100]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id x07GsQLr005165; Mon, 7 Jan 2019 17:54:26 +0100 Subject: Re: [PATCH 1/7] dpkg-raw: Respect file permissions defined by recipe To: Henning Schild Cc: isar-users References: <20190107142049.0c5426a3@md1za8fc.ad001.siemens.net> <20190107151959.2627fcd8@md1za8fc.ad001.siemens.net> <1552f87b-a193-fca2-6496-e94554b21d6f@siemens.com> <30994991-d72e-1a54-6f90-1a89e926e121@siemens.com> <20190107172810.10e0178b@md1za8fc.ad001.siemens.net> From: Jan Kiszka Message-ID: <73e2f06f-9ece-1c7c-739f-b572a109179c@siemens.com> Date: Mon, 7 Jan 2019 17:54:26 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <20190107172810.10e0178b@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: UqE5WXWIr6uo On 07.01.19 17:28, Henning Schild wrote: > Am Mon, 7 Jan 2019 15:26:16 +0100 > schrieb Jan Kiszka : > >> 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 : >>>> >>>>> On 07.01.19 14:20, Henning Schild wrote: >>>>>> Am Wed, 2 Jan 2019 12:34:11 +0100 >>>>>> schrieb Jan Kiszka : >>>>>>> From: Jan Kiszka >>>>>>> >>>>>>> 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 >>>>>>> Signed-off-by: Jan Kiszka >>>>>>> --- >>>>>>>    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. 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 -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux