Previously-present output not removed before rebuilding multiple-output derivation

[civodul]

Suppose you have a multiple-output derivation, and one of its output is already present in the store.

When re-building the derivation, the already-present output is not present.

This leads to an assertion failure at "assert(!S_ISDIR(st.st_mode));" in canonicalisePathMetaData_ because the owner of the already-present output is `root', not the build user.

A possible fix would be to remove any already-present outputs before rebuilding the derivation.

[edolstra]

Already-present outputs cannot be removed in general because they might be live.

We should simply not canonicalize outputs that were already valid.

[civodul]

OK to apply the patch at http://lists.gnu.org/archive/html/bug-guix/2013-06/msg00045.html?

[vcunat]

IMO this fails before computeClosure is even called. The derivation would try to install into a path to which it has no permissions. Either you are able to garbage-collect the obstructing path, or I don't see there could be a good way to fix this problem (except for switching to intensional store, but that would be a really big change).

[civodul]

Vladimír Čunát notifications@github.com skribis:

IMO this fails before computeClosure is even called. The derivation would try to install into a path to which it has no permissions. Either you are able to garbage-collect the obstructing path, or I don't see there could be a good way to fix this problem (except for switching to intensional store, but that would be a really big change).

The patch I posted has been tested and fixes the problem AFAICS.

Ludo’.

[edolstra]

@vcunat That's not a problem because Nix either performs the build in a chroot (where the obstructing paths are not present) or performs magic hash rewriting.

[edolstra]

@civodul I've committed a different fix, namely to let computeClosure() skip paths that were already valid. If I'm not mistaken, your fix has a security hole in that it would allow a build that does "ln /etc/shadow $out" (on systems without hard link restrictions). (There actually is a similar security bug in hash rewriting, see cd49ee0.)

[vcunat]

@edolstra: Ah, I forgot chroots. Is hash rewriting used somewhere (or some analogue of intensional store from your thesis)?

[edolstra]

Yes, it's used when chroots are disabled/unsupported. You can see it in action if you build a multiple-output derivation, garbage-collect one of the outputs, and then build the derivation again.

[civodul]

Wonderful, thanks!