Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Saul Wold <sgw@linux.intel.com>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] package_ipk: apply umask to control and conffiles
Date: Wed, 04 Apr 2012 09:56:36 -0700	[thread overview]
Message-ID: <4F7C7D44.3010609@linux.intel.com> (raw)
In-Reply-To: <4F708F78.4020502@opendreambox.org>

On 03/26/2012 08:47 AM, Andreas Oberritter wrote:
> On 26.03.2012 13:34, Richard Purdie wrote:
>> On Fri, 2012-03-23 at 21:17 +0100, Andreas Oberritter wrote:
>>> On 12.03.2012 16:53, Richard Purdie wrote:
>>>> On Mon, 2012-03-12 at 10:29 -0500, Mark Hatle wrote:
>>>>> On 3/9/12 8:15 PM, Andreas Oberritter wrote:
>>>>>> * Explicitly set umask to 022. Otherwise the build system's
>>>>>>     umask leaks into the image.
>>>>>
>>>>> I'm surprised that do_package_ipk[umask] didn't work.  Perhaps its the way it's
>>>>> being invoked that is the issue.  (If bitbake doesn't run it, but something else
>>>>> does.. then the umask setting doesn't get used.)
>>>>>
>>>>> As for the change of the umask, the changes appear to be specific to the ipk
>>>>> case.  Is this the desired behavior, or could deb and rpm suffer from similar
>>>>> issues?  (I'm not familiar enough with opkg to know how it handles umask
>>>>> settings during package install/rootfs construction..)
>>>>>
>>>>> I believe that RPM sets a default umask when it goes through it's package
>>>>> installs/rootfs generation.  But does DEB?
>>>>
>>>> I'm also a bit worried about this patch. I'd like to understand why a
>>>> task level umask doesn't work. That shouldn't even make any difference
>>>> since the permissions/owners/users from install should be getting
>>>> used...
>>>
>>> can you please give some advise on how to continue with this issue?
>>
>> I understand half the problem now, the files with the issues are ones
>> created during the package_ipk task. That addresses one of my big
>> concerns.
>>
>> The second thing I'd like to understand is why a task level umask
>> doesn't resolve this. Looking at what you tried, this might be as simple
>> as a typo:
>>
>> do_package_ipk[umask] = "022"
>>
>> when you really want:
>>
>> do_package_write_ipk[umask] = "022"
>
> Richard,
>
> thank you, that did it. It wasn't a typo, but lack of understanding of
> the "magic" behind it, as I tried to apply the umask to the
> do_package_ipk function instead of the do_package_write_ipk *task*.
>
> Please see below for an updated patch.
>
> Regards,
> Andreas
>
>> If that works, lets set this for deb and rpm too so we're consistent and
>> I'll merge that patch :)
>
>> From f9e4707d7a619e29530ac144ae1aba9d9e406884 Mon Sep 17 00:00:00 2001
> From: Andreas Oberritter<obi@opendreambox.org>
> Date: Sat, 10 Mar 2012 03:11:57 +0100
> Subject: [PATCH] package_{deb,ipk,rpm}: apply umask to files generated in
>   do_package_write_{deb,ipk,rpm}
>
> * Explicitly set umask to 022. Otherwise the build system's
>    umask may leak into the image.
>
> Signed-off-by: Andreas Oberritter<obi@opendreambox.org>
> ---
>   meta/classes/package_deb.bbclass |    1 +
>   meta/classes/package_ipk.bbclass |    1 +
>   meta/classes/package_rpm.bbclass |    1 +
>   3 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/meta/classes/package_deb.bbclass b/meta/classes/package_deb.bbclass
> index 1f7ec9c..9880258 100644
> --- a/meta/classes/package_deb.bbclass
> +++ b/meta/classes/package_deb.bbclass
> @@ -421,6 +421,7 @@ python do_package_write_deb () {
>   	bb.build.exec_func("do_package_deb", d)
>   }
>   do_package_write_deb[dirs] = "${PKGWRITEDIRDEB}"
> +do_package_write_deb[umask] = "022"
>   addtask package_write_deb before do_package_write after do_package
>
>
> diff --git a/meta/classes/package_ipk.bbclass b/meta/classes/package_ipk.bbclass
> index 565ef93..e4a217b 100644
> --- a/meta/classes/package_ipk.bbclass
> +++ b/meta/classes/package_ipk.bbclass
> @@ -453,6 +453,7 @@ python do_package_write_ipk () {
>   	bb.build.exec_func("do_package_ipk", d)
>   }
>   do_package_write_ipk[dirs] = "${PKGWRITEDIRIPK}"
> +do_package_write_ipk[umask] = "022"
>   addtask package_write_ipk before do_package_write after do_package
>
>   PACKAGEINDEXES += "package_update_index_ipk;"
> diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
> index e83fc55..daa9301 100644
> --- a/meta/classes/package_rpm.bbclass
> +++ b/meta/classes/package_rpm.bbclass
> @@ -1056,6 +1056,7 @@ python do_package_write_rpm () {
>   }
>
>   do_package_write_rpm[dirs] = "${PKGWRITEDIRRPM}"
> +do_package_write_rpm[umask] = "022"
>   addtask package_write_rpm before do_package_write after do_package
>
>   PACKAGEINDEXES += "package_update_index_rpm; createrepo ${DEPLOY_DIR_RPM};"

Merged this patch to OE-Core

Thanks
	Sau!



      reply	other threads:[~2012-04-04 17:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-10  2:15 [PATCH] package_ipk: apply umask to control and conffiles Andreas Oberritter
2012-03-12 15:29 ` Mark Hatle
2012-03-12 15:53   ` Richard Purdie
2012-03-12 16:27     ` Andreas Oberritter
2012-03-23 20:17     ` Andreas Oberritter
2012-03-26 11:34       ` Richard Purdie
2012-03-26 15:47         ` Andreas Oberritter
2012-04-04 16:56           ` Saul Wold [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F7C7D44.3010609@linux.intel.com \
    --to=sgw@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox