Patchwork [RFC,3/3] sstate.bbclass: ensure sstate files are easily shared

login
register
mail settings
Submitter Joshua Lock
Date May 10, 2012, 12:22 a.m.
Message ID <934fed48b0c07e606c80023ba045c6c2471bf1b0.1336608479.git.josh@linux.intel.com>
Download mbox | patch
Permalink /patch/27425/
State New
Headers show

Comments

Joshua Lock - May 10, 2012, 12:22 a.m.
In order to make sstate cache's more easily shared ensure any user of
the system has rwx permission by calling chown on sstate files after
they're created.

Signed-off-by: Joshua Lock <josh@linux.intel.com>
---
 meta/classes/sstate.bbclass |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
Saul Wold - May 10, 2012, 12:27 a.m.
On 05/09/2012 05:22 PM, Joshua Lock wrote:
> In order to make sstate cache's more easily shared ensure any user of
> the system has rwx permission by calling chown on sstate files after
> they're created.
>
> Signed-off-by: Joshua Lock<josh@linux.intel.com>
> ---
>   meta/classes/sstate.bbclass |    1 +
>   1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
> index a8c98e5..6707ecf 100644
> --- a/meta/classes/sstate.bbclass
> +++ b/meta/classes/sstate.bbclass
> @@ -454,6 +454,7 @@ sstate_create_package () {
>   	else
>   		tar -cz --file=$TFILE --files-from=/dev/null
>   	fi
> +	chmod 0777 $TFILE
>   	mv $TFILE ${SSTATE_PKG}
>
>   	cd ${WORKDIR}
Why execute permission, and should it not be restricted to 664 for group 
level write access?  Why would multiple users be writing to the same 
sstate file anyways once it's there it could be read-only since a change 
will trigger a new sstate file, not a re-write of the existing one.

Sau!
Joshua Lock - May 10, 2012, 1:01 a.m.
On 09/05/12 17:27, Saul Wold wrote:
> On 05/09/2012 05:22 PM, Joshua Lock wrote:
>> In order to make sstate cache's more easily shared ensure any user of
>> the system has rwx permission by calling chown on sstate files after
>> they're created.
>>
>> Signed-off-by: Joshua Lock<josh@linux.intel.com>
>> ---
>> meta/classes/sstate.bbclass | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
>> index a8c98e5..6707ecf 100644
>> --- a/meta/classes/sstate.bbclass
>> +++ b/meta/classes/sstate.bbclass
>> @@ -454,6 +454,7 @@ sstate_create_package () {
>> else
>> tar -cz --file=$TFILE --files-from=/dev/null
>> fi
>> + chmod 0777 $TFILE
>> mv $TFILE ${SSTATE_PKG}
>>
>> cd ${WORKDIR}
> Why execute permission, and should it not be restricted to 664 for group
> level write access? Why would multiple users be writing to the same
> sstate file anyways once it's there it could be read-only since a change
> will trigger a new sstate file, not a re-write of the existing one.

For permissions I figured that whichever I went with someone would have 
an alternative suggestion so I went with as indiscriminate as possible 
- that's the main reason this is an RFC.

When I was reproducing the bug and had read-only siginfo file things 
blew up, so I created them writeable, see [1].

Cheers,
Joshua

1. https://bugzilla.yoctoproject.org/show_bug.cgi?id=2041#c9

Patch

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index a8c98e5..6707ecf 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -454,6 +454,7 @@  sstate_create_package () {
 	else
 		tar -cz --file=$TFILE --files-from=/dev/null
 	fi
+	chmod 0777 $TFILE
 	mv $TFILE ${SSTATE_PKG}
 
 	cd ${WORKDIR}