Re: Why is /gnu/store writable by the guixbuild group?

[ludo@gnu.org (Ludovic Courtès)]

Steven Allen <steven@stebalien.com> skribis:

> On 01-22-16, Thompson, David wrote:
>> On GuixSD, /gnu/store is mounted *read-only* and remounted read/write
>> for the purposes of the daemon only.  So, for any particular build, a
>> build user can *only* write to their specific output directories and
>> nothing else.
>
> Got it. Off to fix the Arch package... Unfortunately, I doubt this will
> make grsecurity happy (and TPE is a really nice security feature)
> because the store *could* be mounted read-write somewhere.

What’s TPE (sorry for asking) and how does it complain exactly?

>> Note as well that the items in the store are owned by root and cannot
>> be touched.  The only user that can trash things is the superuser, if
>> they so choose.
>
> FYI, in my Arch install (not GuixSD, as far as I can tell), some of the
> files in /gnu/store/ files are owned by the guixbuild group (but not
> group writable). I assume these are failed in-progress builds (for some
> reason,

Exactly.

> Guix on Arch keeps on trying to build gcc on my poor laptop even
> though I've enabled substitutes but that's another issue...)

That shouldn’t happen, unless you’re using an old version of Guix for
which substitutes are no longer available at hydra.gnu.org.

>> > So, why exactly does the guixbuild group need write access to this
>> > directory? I'd think that the guix-daemon would be responsible for
>> > moving finished builds into the store, not the builders themselves.
>> 
>> Builders write directly to their output directories.  In GNU terms,
>> this is the directory used for './configure --prefix=/gnu/store/foo'.
>
> Then why does /gnu/store need to be writable by the guixbuild group?  If
> the builders can only write to their output directories, e.g.
> /gnu/store/foo, /gnu/store shouldn't need to be writable by guixbuild.

That’s because initially build processes write to their chroot, but when
the build completes, the build process moves the outputs (the results)
back to the store.  See nix/libstore/build.cc in ‘registerOutputs’:

--8<---------------cut here---------------start------------->8---
      if (pathExists(actualPath)) {
          /* Move output paths from the chroot to the Nix store. */
          if (buildMode == bmRepair)
              replaceValidPath(path, actualPath);
          else
              if (buildMode != bmCheck && rename(actualPath.c_str(), path.c_str()) == -1)
                  throw SysError(format("moving build output `%1%' from the chroot to the Nix store") % path);
      }
--8<---------------cut here---------------end--------------->8---

If you look at ‘strace -f -p $(pidof guix-daemon)’ while running ‘guix
build grue-hunter’, the above lines of code translate to:

--8<---------------cut here---------------start------------->8---
7519  --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=7544, si_status=0, si_utime=0, si_stime=0} ---
7519  lstat("/gnu/store/660hdld3sc7laz8kw871pd3yyg9khs5m-grue-hunter-1.0.drv.chroot/gnu/store/h6sdfqzv4xbydwiafiqvrw0d5505l1l8-grue-hunter-1.0", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
7519  rename("/gnu/store/660hdld3sc7laz8kw871pd3yyg9khs5m-grue-hunter-1.0.drv.chroot/gnu/store/h6sdfqzv4xbydwiafiqvrw0d5505l1l8-grue-hunter-1.0", "/gnu/store/h6sdfqzv4xbydwiafiqvrw0d5505l1l8-grue-hunter-1.0") = 0
--8<---------------cut here---------------end--------------->8---

> My only reservation with this is that directories in /gnu/store may or
> may not be "complete" (one could have half-completed builds). However,
> given that no build can go from complete to in-progress (builds are
> deterministic so there are no rebuilds), this isn't really a problem as
> long as programs never assume that all builds in the store are complete.

As Andreas said, there’s a database (/var/guix/db/db.sqlite by default)
that contains a table listing valid store entries, among other things.

>> > On a related note, why do all builders use guixbuild as their primary
>> > group.
>> In the long term, it would be cool to just use user namespaces...
>
> In the short term, is there any reason not to give each of these users
> its own group?

Would it make a difference?

I should point out that this part (the daemon) is inherited from the Nix
project, which was started long ago, and notably long before user name
spaces came into existence.

HTH,
Ludo’.