From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: Directory permissions and ownership -- RFC
Date: Tue, 21 Jun 2011 23:05:35 +0100 [thread overview]
Message-ID: <1308693935.20015.37.camel@rex> (raw)
In-Reply-To: <4E00ED2C.1040708@windriver.com>
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
next prev parent reply other threads:[~2011-06-21 22:09 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 [this message]
2011-06-21 22:13 ` Mark Hatle
2011-06-22 4:51 ` Mark Hatle
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=1308693935.20015.37.camel@rex \
--to=richard.purdie@linuxfoundation.org \
--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.