Re: Building, packaging and updating Guix with confidence

[Bengt Richter <bokr@bokr.com>]

Hi Josselin,

tl;dr:
I naively don't buy the rationale against a non-root guix daemon :)
Skip to [2] if tl ;)

On +2022-07-21 18:10:53 +0200, Josselin Poiret wrote:
> Hello,
> 
> bokr@bokr.com writes:
> > Naively:
> >
> > Why does "the" guix daemon per se need root access at all?
> 
> The main thing is that all files in the store end up being written by
> the guix daemon user.

IIUC, that would be guixrootd per se, not the homeless guixbuilder{0-10}
users created by the default install, right? (IIUC the latter are
meant to allow guixrootd to shed its root write privilege by spawning
a user mode continuation, so to speak?)

> ... So if we want the files to be easily
> substitutable, they'd need to have a fixed uid/gid,

Why? "Easily" in what way? untarring tarballs?

Even if tar sets bogus external file system metadata,
UIAM the only privilege you need is ownership, and neither
guix nor the installer need to run as root themselves
to get ownership. That can be done by a tiny helper
whose source you can see on one page, and whose execution
you can limit to a user such as the single-writer guixstored,
which UIAM can then chmod and chown at will to share or not.

I don't believe in blanket permissions to accomplish
a tiny important priviliged action. I want to see it
factored out for auditability and comprehensibility.

(Here I did s/guixrootd/guixstored/ as a name for a non-root
user which has exclusive control over gnu/store because
it creates /home/guixstored/gnu/store thus in its home directory
and no other user has write access to it except by talking to guixstored via
message or sharing read-only files if mounted and reachable and permitted
by guixstored setting perissions on files it owns.

> ... and the only one we
> can guarantee is root.

But why would you have to? ISTM not necessary.

> ... Other than that, it needs to use a bunch of
> Linux namespaces to isolate the builds from the rest of the system,
You mean like -G from 

--8<---------------cut here---------------start------------->8---
useradd -g guixbuild -G guixbuild${KVMGROUP}     \
                    -d /var/empty -s "$(which nologin)" \
                    -c "Guix build user $i" --system    \
                    "guixbuilder${i}";
            _msg "${PAS}user added <guixbuilder${i}>"
        fi
--8<---------------cut here---------------end--------------->8---
YOW! running as root AND being able to do KVM stuff?
My naive paranoia button has been pushed, and I don't want to
do the searching for info to calm myself ;/

BTW, above snip was from guix clone repo pull as of
┌──────────────────────────────────────────────────────────┐
│ # $ git log --pretty=medium --grep 'install\.sh'|head -3 │
├──────────────────────────────────────────────────────────┤
│ commit 3348e485b7229e062e563945ed7e6ac216f25125          │
│ Author: Philip McGrath <philip@philipmcgrath.com>        │
│ Date:   Sun Jul 3 22:35:03 2022 -0400                    │
└──────────────────────────────────────────────────────────┘

> which depending on the kernel build-time configuration might not be
> possible when unprivileged.
>

IWT think that goes away if you run a single-writer daemon
on the local OS, and let the kernel use its namespaces to
keep the users from trampling on each other (any more than
they already maybe can with the current setup).

If the OS can't separate users, ISTM everbody is kind-of root in effect,
but then maybe we can run a single user thread as if root, if you have
an environment where that's useful -- maybe cloud virtual pcs?

Communicating would be an adapter problem, but virtual pcs
can boot fully fledged linux these days, I think, and it seems
doubtful that you would run a big guix build ON a raspberry pi
even though TARGETING an rpi makes lots of sense.

Whew, I've got to stop re-editing this :/

[2]:
So, do you see any real obstacles to making guixrootd an ordinary user
(in the sense of /home/ordinary_user/ ) and calling it
guixstored instead, with an ordinary /home/guixstored/ home directory
(where it has natural protection as guixstored:guixstored on useradd
creation, with added group guixbuilder for helper r/o sharing, which
as owner it can control)?

However many guixbuilder0{1..9}:guixbuilder0{1..9} helper users are created,
(plus guixbuilder10:guixbuilder10 in the default naming :)
they would also belong to the guixbuilder extra group
(no suffixed number) but they only would have read access to parts of
/home/guixstored/gnu/store/... unless guixstored as
owner sets other permissions for the guixbuilder group.

I'm not seeing why there needs to be any guix daemon running as root :)

But this means you can't just uncompress files, metadata and all,
for substitution purposes, which I guess you were alluding to with
"...can't easily...", right?

But IWT that guixstored could use a tiny helper to get ownership, as above.

Becoming owner by using a factored-out-tiny-helper to chown untarred stuff
should be safer than running bigstuff as root IWT).

It can then create and exclusively control /home/guixstored/gnu/store/...
and allow guixbuilder{1..10} user-helpers to have group read access to
 /home/guixstored/gnu/store/... I am imagining smallish /home directories
 /home/guixbuilder{1..10}/... for those helpers to maintain their own
 states in whatever they are helping with, and outputting their final results
 to guixstored by the most efficient means available to the process.

If they're on the same SOC or on the other side of the globe will make
a difference, but IMO that's an adaper concern which should not
affect the design of the essential guile/guix package management
sources or their hashes.
 
Well, IMHO any adaptations to particular file systems or transfer
protocols should be considered as just that: adapters, orthogonal
to the essential data transforming that guix/guile does, where
all data is just various interpretations of #vu8 compositions.

Otherwise, if adaptor cruft is incorporated into the essential
guix package manager, IMHO it will grow into a rube-goldberg
kludge-ball. Let it manage libraries of adapter implementations,
but keep them scrupulously outside, along with the definitions of their
dependencies on the metadata describing what they are adapting to.

I think basically everything guix/guile reads and writes as it
does its package management should have an official documented
#vu8 representation. Including snarfed and transformed foreign
metadata.

> Best,
> -- 
> Josselin Poiret

For reference, this is a remnant from an old install, but I assume this
is still what the intaller creates (right?).
┌─────────────────────────────────────────────────────────────────────────┐
│                        # $ grep guix /etc/passwd                        │
├─────────────────────────────────────────────────────────────────────────┤
│ guixbuilder01:x:998:998:Guix build user 01:/var/empty:/usr/sbin/nologin │
│ guixbuilder02:x:997:998:Guix build user 02:/var/empty:/usr/sbin/nologin │
│ guixbuilder03:x:996:998:Guix build user 03:/var/empty:/usr/sbin/nologin │
│ guixbuilder04:x:995:998:Guix build user 04:/var/empty:/usr/sbin/nologin │
│ guixbuilder05:x:994:998:Guix build user 05:/var/empty:/usr/sbin/nologin │
│ guixbuilder06:x:993:998:Guix build user 06:/var/empty:/usr/sbin/nologin │
│ guixbuilder07:x:992:998:Guix build user 07:/var/empty:/usr/sbin/nologin │
│ guixbuilder08:x:991:998:Guix build user 08:/var/empty:/usr/sbin/nologin │
│ guixbuilder09:x:990:998:Guix build user 09:/var/empty:/usr/sbin/nologin │
│ guixbuilder10:x:989:998:Guix build user 10:/var/empty:/usr/sbin/nologin │
│ guixrootd:988:998:Guix root daemon:/home/guixrootd:                     │
└─────────────────────────────────────────────────────────────────────────┘

So WDYT? :)
--
Regards,
engt Richter