| 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
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!
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}
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(-)