Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#11660 closed defect (fixed)

docutils files not world-readable

Reported by: jdemeyer Owned by: tbd
Priority: blocker Milestone: sage-4.7.1
Component: packages: standard Keywords:
Cc: Merged in: sage-4.7.1.rc2
Authors: Jeroen Demeyer Reviewers: Leif Leonhardy
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by jdemeyer)

The new docutils spkg from #10166 has its src directory not world-readable which causes trouble when running Sage as a different user from the user which compiled Sage. For example, the following fails from the notebook:

sage: EllipticCurve?
IOError: [Errno 13] Permission denied: '/usr/local/sage/sage-4.7.1.rc0/local/lib/python2.6/site-packages/docutils/writers/html4css1/html4css1.css'

This problem is not upstream, it was introduced in Sage.

New spkg simply changing the permission of the files inside the src directory of the spkg: http://boxen.math.washington.edu/home/jdemeyer/spkg/docutils-0.7.p0.spkg

Change History (12)

comment:1 Changed 8 years ago by jdemeyer

  • Authors set to Jeroen Demeyer
  • Description modified (diff)
  • Status changed from new to needs_review
  • Summary changed from docutils installs some files not-world-readable to docutils files not world-readable

comment:2 Changed 8 years ago by leif

  • Reviewers set to Leif Leonhardy
  • Status changed from needs_review to positive_review

I would have added a note to Special Update/Build? Instructions (and tagged the new changeset to docutils-0.7.p0) though.

comment:3 follow-up: Changed 8 years ago by kini

Ideally this should be done with chmod in the setup script. Eventually we will want to transition to a build system where upstream sources remain untouched in the src/ directory (which is why they're not under our revision control).

comment:4 in reply to: ↑ 3 Changed 8 years ago by leif

Replying to kini:

Ideally this should be done with chmod in the setup script. Eventually we will want to transition to a build system where upstream sources remain untouched in the src/ directory (which is why they're not under our revision control).

Yep, but it's not always clear if someone just extracted the upstream sources the wrong way.

Jeroen, did you report this upstream? (Apparently only some files had wrong permissions, so I assume they came indeed from upstream.)

P.S.: Feel free to consider #11658 critical or a blocker; #11519 can be closed as a duplicate.

comment:5 follow-ups: Changed 8 years ago by vbraun

+1 for fixing this in the setup script and setting the source files to reasonable values after unpacking. I suggest the following:

chmod -R u+rwX,go+rX src

Note that the capital X sets executable permissions for directories and files with u+x ONLY. To make sure that we don't trip over a posix issue I tested it on skynet/mark2 and it works on solaris, too.

comment:6 in reply to: ↑ 5 Changed 8 years ago by leif

Replying to vbraun:

I suggest the following:

chmod -R u+rwX,go+rX src

I guess you meant

chmod -R u+rw,go+rX src

as u+X doesn't make much sense (though it could in principle happen that some file has execute permissions for the group or others but not the owner himself, but such should certainly be reported upstream).

comment:7 in reply to: ↑ 5 ; follow-up: Changed 8 years ago by jdemeyer

Replying to vbraun:

+1 for fixing this in the setup script and setting the source files to reasonable values after unpacking.

The problem with this is that it doesn't allow for special cases. Perhaps there are scenarios where unusual permissions make sense.

comment:8 follow-up: Changed 8 years ago by vbraun

  1. The chmod command will only increase the permissions, so it can't break anything as long as upstream has at least a minimum of sanity
  2. Any makefile that does not use install (with explicit permissions) to install files is broken, we just haven't triggered the bug yet.

comment:9 Changed 8 years ago by jdemeyer

  • Description modified (diff)

comment:10 in reply to: ↑ 8 Changed 8 years ago by jdemeyer

Replying to vbraun:

Any makefile that does not use install (with explicit permissions) to install files is broken, we just haven't triggered the bug yet.

You are probably right, but unfortunately we cannot fix every spkg to do this :-)

comment:11 Changed 8 years ago by jdemeyer

  • Merged in set to sage-4.7.1.rc2
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:12 in reply to: ↑ 7 Changed 8 years ago by kini

Replying to jdemeyer:

Replying to vbraun:

+1 for fixing this in the setup script and setting the source files to reasonable values after unpacking.

The problem with this is that it doesn't allow for special cases. Perhaps there are scenarios where unusual permissions make sense.

Sure. When I said "the setup script" I meant the spkg-install script in an individual SPKG. So those scenarios could be handled on an individual basis.

Note: See TracTickets for help on using tickets.