Ludovic Courtès <[email protected]> writes: >> --8<---------------cut here---------------start------------->8--- >> May 06 02:59:56 HOST kernel: audit: type=1400 audit(1778029196.515:366): >> apparmor="DENIED" operation="open" profile="guix-daemon" >> name="/proc/2125022/net/if_inet6" pid=2125022 comm="guix-daemon" >> requested_mask="r" denied_mask="r" fsuid=997 ouid=0 >> --8<---------------cut here---------------end--------------->8--- > > That must come from ‘haveGlobalIPv6Address’. What does AppArmor do in > this case? Does it terminate the process?
Based on the error message, I would assume it causes EPERM to be
returned by 'open'.
>
> The daemon does all this:
>
> if(fixedOutput) {
> if(findProgram(settings.slirp4netns) == "")
> printMsg(lvlError, std::format("`{}' can't be found in PATH, network
> access disabled", settings.slirp4netns));
> else {
> if(!pathExists("/dev/net/tun"))
> printMsg(lvlError, "`/dev/net/tun' is missing, network access
> disabled");
> else {
> useSlirp4netns = true;
> ctx.ipv6Enabled = haveGlobalIPv6Address();
> }
> }
> }
>
> … even though in the end this is handled by “builtin:git-download”,
> which doesn’t need any of this.
That section is nested inside an 'if (useChroot) { ... }', which should
be false in the case of builtins. I suspect it's the native-inputs
mentioned that are failing to build - that is, it's "vendor" whose build
is failing to start, not "wire" directly. "vendor" uses a special
origin method, which is why the non-builtin fixed-output machinery kicks
in.
It seems that apparmor doesn't think that guix-daemon should be able to
access /proc/self/net/if_inet6. We could just detect the EPERM and
default to either assuming global ipv6 connectivity or lack thereof, but
if this apparmor profile originates from guix to begin with, it would
probably be better to fix the profile, especially because there are
likely other, more necessary files that will need to be allowed anyway.
I'm not familiar with AppArmor, but it looks like
etc/apparmor.d/guix-daemon has entries that look like:
--8<---------------cut here---------------start------------->8---
owner @{PROC}/@{pid}/{fd/,environ} r,
owner @{PROC}/@{pid}/oom_score_adj w,
owner @{PROC}/@{pid}/uid_map rw,
owner @{PROC}/@{pid}/gid_map rw,
owner @{PROC}/@{pid}/setgroups w,
--8<---------------cut here---------------end--------------->8---
I assume that "r" is "read" and "w" is "write", so having done no
research on this, maybe something like:
owner @{PROC}/@{pid}/net/if_inet6 r,
could get us past this issue? In general though, it looks like the
apparmor profile might not have been designed with slirp4netns in mind
(perhaps it predates it?) - here are some filenames that I don't see
mentioned in it:
/dev/net/tun
/proc/sys/net/ipv6/conf/tap0/accept_dad
/proc/sys/net/ipv6/conf/tap0/accept_ra
/proc/sys/net/ipv4/conf/all/route_localnet
/proc/self/mountinfo
/proc/self/net/if_inet6
I don't know how the guix-daemon profile interacts with whatever
system-wide configuration there is, so it may be that not everything
that gets accessed needs to be listed there.
- reepca
signature.asc
Description: PGP signature
