From: Joshua Lock <josh@linux.intel.com>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Cc: Chris Larson <clarson@kergoth.com>
Subject: Re: [RFC PATCH 0/3] Shared state for all !
Date: Wed, 09 May 2012 18:05:33 -0700 [thread overview]
Message-ID: <4FAB145D.4080001@linux.intel.com> (raw)
In-Reply-To: <CABcZANkTB3_QkBcMycY9Z+pZndz7JmOUAksvsQSSiwhHE7vZnQ@mail.gmail.com>
On 09/05/12 17:50, Chris Larson wrote:
> On Wed, May 9, 2012 at 5:22 PM, Joshua Lock<josh@linux.intel.com> wrote:
>> In Yocto #2041[2] Mark reported an issue with reusing shared state as a
>> different user on the same machine.
>>
>> Since the whole purpose of shared state is that it be shared I decided to dig
>> into this issue. I wanted to at least be able to use the shared-state cache of
>> a different user without error, even if all of the objects aren't actually used
>> (i.e. native, at least on the Edison branch I did most of the testing with).
>>
>> This is an RFC mainly because it changes the permissions of created directories,
>> sstate files and siginfo files from what they have traditionally been.
>>
>> There is more of the rhyme an reason in the patch commit headers and comments
>> but tl;dr bb.mkdirhier directories will be 0777 (rwxrwxrwx) with this patch, as
>> will all of the contents of sstate-cache (siginfo and tgz) files.
>>
>> This is actually what one would expect from reading the Python API docs for
>> os.makedirs "The default mode is 0777 (octal)."[1] but not what actually happens
>> on most modern Linux systems thanks to umask.
>>
>> Please review the following changes for suitability for inclusion. If you have
>> any objections or suggestions for improvement, please respond to the patches. If
>> you agree with the changes, please provide your Acked-by.
>
> 777 seems questionable to me, personally. Generally collaboration
> happens amongst folks within a group, and chmod g+s makes that easier.
> I'd expect 775 to be a more sane value, myself.
Do you mean for bb.mkdirhier calls, the tgz files, the siginfo files or
everything?
I went with 777 for mkdirhier as that's the default of os.makedirs
before umask is involved. I would likely have picked rw-rw-r-- (664) if
I weren't trying to request comments.
Cheers,
Joshua
--
Joshua Lock
Yocto Project
Intel Open Source Technology Centre
next prev parent reply other threads:[~2012-05-10 1:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-10 0:22 [RFC PATCH 0/3] Shared state for all ! Joshua Lock
2012-05-10 0:22 ` [RFC PATCH 1/3] lib/bb/utils.py: add optional mode parameter to bb.utils.mkdirhier() Joshua Lock
2012-05-10 11:19 ` Richard Purdie
2012-05-10 0:22 ` [RFC PATCH 2/3] lib/bb/siggen.py: create permissive files and directories Joshua Lock
2012-05-10 11:22 ` Richard Purdie
2012-05-10 16:10 ` Joshua Lock
2012-05-10 0:22 ` [RFC PATCH 3/3] sstate.bbclass: ensure sstate files are easily shared Joshua Lock
2012-05-10 0:27 ` Saul Wold
2012-05-10 1:01 ` Joshua Lock
2012-05-10 0:50 ` [RFC PATCH 0/3] Shared state for all ! Chris Larson
2012-05-10 1:05 ` Joshua Lock [this message]
2012-05-10 2:15 ` Chris Larson
2012-05-10 2:32 ` Joshua Lock
2012-05-10 3:10 ` Joshua Lock
2012-05-10 3:14 ` Joshua Lock
2012-05-10 5:16 ` Khem Raj
2012-05-10 16:12 ` Joshua Lock
2012-05-10 16:31 ` Khem Raj
2012-05-10 7:25 ` Koen Kooi
2012-05-10 16:05 ` Joshua Lock
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=4FAB145D.4080001@linux.intel.com \
--to=josh@linux.intel.com \
--cc=clarson@kergoth.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.