docutils files not-world-readable (4.7.1 blocker)

[Jeroen Demeyer]

This is a blocker for 4.7.1: the new docutils (#10166) installs some
files not-world-readable which causes trouble when running Sage as a
different user from the user which compiled Sage. In particular, the
help from the notebook does *not* work.

Please see #11660 and review:
http://trac.sagemath.org/sage_trac/ticket/11660

[Jeroen Demeyer]

See also analogous tickets for other packages:
#11661 (gap)
#11662 (moin)
#11663 (singular)
#11664 (polybori)

I can create the spkgs, but somebody needs to review them.

Jeroen.

[leif]

On 8 Aug., 15:54, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> On 2011-08-08 15:01, Jeroen Demeyer wrote:
>
> > This is a blocker for 4.7.1: the new docutils (#10166) installs some
> > files not-world-readable which causes trouble when running Sage as a
> > different user from the user which compiled Sage.  In particular, the
> > help from the notebook does *not* work.
>
> > Please see #11660 and review:
> >http://trac.sagemath.org/sage_trac/ticket/11660

Now has positive review.

> See also analogous tickets for other packages:
> #11661 (gap)
> #11662 (moin)
> #11663 (singular)
> #11664 (polybori)
>
> I can create the spkgs, but somebody needs to review them.

We could also create some post-install script that checks (and
optionally fixes) file permissions.

I think it's ok to have all files o=rX; sysadmins may (and will
perhaps) chmod -R o-rwx $SAGE_ROOT/ anyway.

Independent of that, if upstream packages ship with wrong permissions,
we should also report that upstream. (And checking file permissions
should be part of the review process; we should perhaps add a note on
that to the Developer's Guide.)


-leif

[Jeroen Demeyer]

On 2011-08-08 20:11, leif wrote:
> We could also create some post-install script that checks (and
> optionally fixes) file permissions.

-1 because there is no reason to do it *post-install*, it would add
unnecessary complications to the build process and more potential for
unportable behavious.

Instead, we should ship the spkgs already with the correct permissions.
If you want to automate it, then either do it upon "sage -spkg" or when
merging the spkg (as part of the merger script). I can trivially
implement the latter.

Jeroen.

[leif]

On 8 Aug., 20:59, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> On 2011-08-08 20:11, leif wrote:
> > We could also create some post-install script that checks (and
> > optionally fixes) file permissions.
>
> -1 because there is no reason to do it *post-install*, it would add
> unnecessary complications to the build process and more potential for
> unportable behavious.

I didn't mean "instead", but more or less "post mortem"; i.e., an
additional script that just checks, and optionally fixes the Sage tree
after installation, since similar might happen again if people aren't
cautious.

> Instead, we should ship the spkgs already with the correct permissions.

Of course, i.e. I'd also prefer doing a chmod if necessary in spkg-
install rather than shipping modified upstream sources, since we may
well ship them separately in the future.

>  If you want to automate it, then either do it upon "sage -spkg" or when
> merging the spkg (as part of the merger script).  I can trivially
> implement the latter.

See above. I'd just run a script that checks file permissions *of the
installed files* after an spkg has been installed when testing an
spkg.


-leif

[leif]

See http://trac.sagemath.org/sage_trac/ticket/11663#comment:6 ff. for
reasons why it is in general *not* sufficient to just change the
permissions of all upstream files (in src/).


-leif

[Jeroen Demeyer]

On 2011-08-08 15:54, Jeroen Demeyer wrote:
> See also analogous tickets for other packages:
> #11661 (gap)
> #11662 (moin)
> #11663 (singular)
> #11664 (polybori)

I have updated spkgs for these, they all need review. I have built Sage
with these new spkgs and now all files after the Sage build have
permission at least 0444 and all directories at least 0555.

Please review these 4.7.1 blockers,
thanks,
Jeroen.

[leif]

On 9 Aug., 14:00, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> > See also analogous tickets for other packages:
> > #11661 (gap)
> > #11662 (moin)
> > #11663 (singular)
> > #11664 (polybori)

> Please review these 4.7.1 blockers,

Sorry, I did not notice the others were blockers for 4.7.*1* when
changing the subject.

#11663 now has positive review.


-leif

[leif]

On 9 Aug., 16:32, leif <not.rea...@online.de> wrote:
> On 9 Aug., 14:00, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
>
> > > See also analogous tickets for other packages:
> > > #11661 (gap)
> > > #11662 (moin)
> > > #11663 (singular)
> > > #11664 (polybori)
> > Please review these 4.7.1 blockers,
>

> #11663 now has positive review.

Now also #11661.


-leif

[leif]

And #11664, too (by Alexander Dreyer), so the only remaining one is
#11662 (MoinMoin), which I'll review soon unless somebody else is
quicker.


-leif

[leif]

Did so.

Now all of the above tickets have positive review.


-leif

[Alexander Dreyer]

> >  If you want to automate it, then either do it upon "sage -spkg" or when
> > merging the spkg (as part of the merger script).  I can trivially
> > implement the latter.

I'd suggest to patch sage-pkg to provide clean spkgs (see here
http://trac.sagemath.org/sage_trac/ticket/11676).
But as I understand, this is not intended here? I'd prefer this,
because I realized that the spkg also makes my username and group
public.

[leif]

On 10 Aug., 10:34, Alexander Dreyer

<alexander.dre...@itwm.fraunhofer.de> wrote:
> > >  If you want to automate it, then either do it upon "sage -spkg" or when
> > > merging the spkg (as part of the merger script).  I can trivially
> > > implement the latter.
>
> I'd suggest to patch sage-pkg to provide clean spkgs (see here http://trac.sagemath.org/sage_trac/ticket/11676).
> But as I understand, this is not intended here?

There's in principle no point in making all the *source* files world-
readable, the point is that the *installed* files should be world-
readable.

One usually installs files with a "BSD-like" 'install' program, which
takes a '-m' option for specifying the mode (permissions).

If a package just uses 'cp' instead, this can be problematic. Then the
source files which are copied should already have the appropriate
permissions and 'cp -p' should be used, since otherwise they will be
modified according to the current umask.

> I'd prefer this,
> because I realized that the spkg also makes my username and group
> public.

'tar' does this, by default.


-leif

[Alexander Dreyer]

Hi everyone!

> If a package just uses 'cp' instead, this can be problematic. Then the
> source files which are copied should already have the appropriate
> permissions and 'cp -p' should be used, since otherwise they will be
> modified according to the current umask.

Thanks for this remark, I'll check "my" spkg for this.

>> I'd prefer this,
>> because I realized that the spkg also makes my username and group
>> public.
>
> 'tar' does this, by default.

Sorry, I wanted to say: I don't like the default (making my data public).

My best,
Alexander
--
Dr. rer. nat. Dipl.-Math. Alexander Dreyer

Abteilung "Systemanalyse, Prognose und Regelung"
Fraunhofer Institut f�r Techno- und Wirtschaftsmathematik (ITWM)
Fraunhofer-Platz 1
67663 Kaiserslautern

Telefon +49 (0) 631-31600-4318
Fax +49 (0) 631-31600-1099
E-Mail alexande...@itwm.fraunhofer.de
Internet http://www.itwm.fraunhofer.de/sys/dreyer.html