All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: Directory permissions and ownership -- RFC
Date: Tue, 21 Jun 2011 23:51:00 -0500	[thread overview]
Message-ID: <4E0174B4.3020207@windriver.com> (raw)
In-Reply-To: <4E0117A5.4070400@windriver.com>

On 6/21/11 5:13 PM, Mark Hatle wrote:
> I like that better then trying to wrap do_install and such with special code.
> 
> It should be fairly easy to set the default for do_install and do_package then.
>  I wonder if there would be a way to "notice" and flag as possible errors tasks
> running between do_install and do_package (in a single recipe) that may need the
> umask set as well.
> 
> --Mark

I worked out a patch to bitbake for this:

http://git.pokylinux.org/cgit.cgi/poky-contrib/commit/?h=mhatle/bitbake&id=abc25d84b3c0b766bb5d45c0354936eaa4d605c4

The associated changes to oe-core:

Revert of the original umask patch:

http://git.pokylinux.org/cgit.cgi/poky-contrib/commit/?h=mhatle/perms&id=845ae082627c6a25304e10e72c655e9197f62c01

New patch that enables umask is specific areas:

http://git.pokylinux.org/cgit.cgi/poky-contrib/commit/?h=mhatle/perms&id=03eb6afb4d1d40ef421085d847cbc42e1795863f

---

Any comments.  I'm not sure I like this task approach, simply because it's more
complicated.  But what I am testing now enables umask of 022 in:

do_install
do_package
do_rootfs
rootfs_<pkg>_do_rootfs
do_populate_sysroot
adt-installer_1.0.bb: do_deploy
linux-tools.inc: do_install_perf

I think that covers everywhere it will be needed...

--Mark

> On 6/21/11 5:05 PM, Richard Purdie wrote:
>> On Tue, 2011-06-21 at 14:12 -0500, Mark Hatle wrote:
>>> On 6/21/11 1:57 PM, Phil Blundell wrote:
>>>> On Tue, 2011-06-21 at 11:43 -0500, Mark Hatle wrote:
>>>>> Adjust the umask to 022.  This resolves the problem of dynamically generated
>>>>> directories (mkdir -p) and specific files (touch foo) having odd permissions.
>>>>>
>>>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mhatle/perms&id=d8470b6a8efdbba04cef5d4dc1ce12720fe83621
>>>>
>>>> Are you confident that this isn't going to break anything like
>>>> group-shared DL_DIRs?  I'm not entirely thrilled about forcing the umask
>>>> to 022 for everything that bitbake does, although I can see that making
>>>> it be so for particular tasks like do_install() might have some merit.
>>>> Even in the latter case, though, I wonder whether we should just be
>>>> paying more attention to recipe hygiene and using "install -m ..." with
>>>> the permissions that we actually want.
>>>
>>> This is why I bring this up.. I'm a bit concerned that doing it generally will
>>> have unintended consequences.  So far I am not aware of any.  Moving it to a
>>> different place in the process may be better.  The only issue I've found so far
>>> is that just coding int into "do_install" really isn't an option.  Between the
>>> custom do_install components, various classes, etc.. it's difficult in the
>>> current infrastructure to find a centralized location to set the value.
>>>
>>> (I'd love to be corrected if someone things of another way of doing it.)  The
>>> setting of the umask is a very low cost operation, so doing it for certain steps
>>> shouldn't cause a performance penalty... but until we figure that out this is
>>> the best and easiest solution I've come up with.
>>
>> How about a umask flag for tasks?
>>
>> If bitbake sees it for a given task it would set the umask as indicated
>> for the task. Cheap and easy and would only impact do_install tasks...
>>
>> Cheers,
>>
>> Richard
>>
>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core




  reply	other threads:[~2011-06-22  4:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-21 16:43 Directory permissions and ownership -- RFC Mark Hatle
2011-06-21 18:57 ` Phil Blundell
2011-06-21 19:12   ` Mark Hatle
2011-06-21 21:09     ` Phil Blundell
2011-06-21 21:27       ` Mark Hatle
2011-06-21 21:37         ` Phil Blundell
2011-06-22  0:35           ` Mark Hatle
2011-06-22  5:47         ` Anders Darander
2011-06-21 21:32     ` Koen Kooi
2011-06-21 21:41       ` Mark Hatle
2011-06-21 21:52         ` Phil Blundell
2011-06-21 21:58           ` Phil Blundell
2011-06-21 22:05     ` Richard Purdie
2011-06-21 22:13       ` Mark Hatle
2011-06-22  4:51         ` Mark Hatle [this message]
2011-06-22 14:04           ` Mark Hatle

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=4E0174B4.3020207@windriver.com \
    --to=mark.hatle@windriver.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.