Gallery creation fails if THEMES_PATH is readonly

[B. Kelly]

I'm seeing this on NixOS, where installed software is all stored on a read-only filesystem, but I suspect it can be reproduced on any system where the contents of THEMES_PATH have mode a-w.

I've reproduced it on both 2.2 and HEAD; the specific error is different (since HEAD no longer has a custom copytree implementation), but the symptom is that when running sigal build, it processes all the images fine and then dies with permission denied when attempting to copy the theme files into place.

As best I can figure, what happens is this:

• it gets to this point in writer.py and copies $THEMES_PATH/default/ into static/, preserving permissions. This means that if THEMES_PATH is readonly, the copy will inherit that.
• it then tries to copy the files for the specific theme into place, and can't because everything in static/ has been marked readonly.

Note that THEMES_PATH doesn't need to be writeable by the user invoking sigal -- e.g. it's ok if it's installed somewhere in /usr/share and has permissions 755:root:root -- but it has to have that write bit set so it'll be carried over by the copytree.

I don't know what's a good solution to this. copytree lets you specify a custom copy function, so you could pass it something other than copy2 that doesn't preserve permissions or calls os.chmod afterwards to make sure the files are writeable, but that won't stop it from copying directory permissions over. As a quick and dirty hack, I've patched it to let me specify THEMES_PATH externally (via the SIGAL_THEMES_PATH environment variable) and then copied the entire themes dir into ~/.cache/sigal/ and made it writeable, but I don't think that's a production-ready fix.

[Simon Conseil]

Not sure what's the best solution, copying the permissions seemed like a reasonable default. Maybe we should just ensure that the directories created by sigal when copying files (mostly static and its sub-directories I guess) remain writable.

[B. Kelly]

I do think it's a reasonable default, since on most distros sigal's templates are going to be installed as root-writeable and that's sufficient to avoid this problem -- it just doesn't work in "weird" situations like NixOS, or when you're running off a liveCD, or the like.

Hitting every directory with chmod after copy to make sure it's writeable would be sufficient to fix this, I think. Annoyingly, copytree doesn't seem to have any way to turn off copying of directory permissions (i.e. use umask instead), so it'll have to be a post hoc fix.

[amesgen]

I ran into the same problem, and created a small patch in #471 which fixes the permissions after the fact.

I tested the changes using this overlay:

final: prev: {
  sigal = prev.sigal.overrideAttrs (_: {
    patches = [
      (prev.fetchpatch {
        url = "https://github.com/saimn/sigal/commit/0bf932935b912f5a4b594182b347f4698a0052dc.patch";
        sha256 = "sha256-h9m5o2RXkNiN36hF97iLCr6JP8+dcGYWM8N0sALFnvw=";
      })
    ];
  });
}