Noé Lopez <noe@noé.eu> skribis:

>>> juin 01 11:01:34 rosa kernel: audit: type=1400 audit(1780304494.536:211):
>>> apparmor="DENIED" operation="file_receive" class="file" profile="guix-
>>> daemon" name="/disconnected/var/cache/nscd/group" pid=12877 comm="guix-
>>> daemon" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
>>> juin 01 11:01:39 rosa kernel: audit: type=1400 audit(1780304499.408:212):
>>> apparmor="DENIED" operation="capable" class="cap" profile="guix-daemon"
>>> pid=12886 comm="guix-daemon" capability=7  capname="setuid"
>>>
>>> So maybe there is an apparmor issue indeed? I know absolutely nothing about
>>> apparmor, so any advice on this is appreciated.
>>
>> I believe nscd sends file descriptors to its clients over sendmsg(2) so
>> they can mmap the cache.  Presumably, it’s that file descriptor exchange
>> that AppArmor is forbidding here.

[...]

> In the logs it shows that its specifically the host file
> /var/cache/nscd/group (from outside of build environment) and “setuid”
> that was blocked.
>
> Presumably, the setuid failure is probably important, while the nscd
> cache can be ignored.

‘setuid’ is the second line of the log, unrelated to the first one.

> We can authorize these two in the AppArmor profile. But I would only
> authorize the setuid, since in principle we don’t want files from
> outside the build environment to get in. Also the nscd cache would be of
> no use there.

guix-daemon, like any program linked against glibc, talks to nscd when
it calls ‘getgr’ and similar functions; these functions result in nscd
sending a read-only file descriptor to the user process, which then
mmaps the corresponding cache file, /var/cache/nscd/group for ‘getgr’.

My guess is that this is what AppArmor is preventing, but perhaps I’m
misinterpreting this first line?

> Patch at https://codeberg.org/guix/guix/pulls/9028

Problem is that, when running unprivileged, guix-daemon does not call
setuid(2) because that would fail.

David, what does “ps aux | grep guix-daemon” show on your machine?

Thanks in advance,
Ludo’.

Reply via email to