[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ludovic Courtès
Subject: Re: Why is /gnu/store writable by the guixbuild group?
Date: Sat, 23 Jan 2016 21:56:46 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Steven Allen <address@hidden> skribis:

> On 01-22-16, Ludovic Courtès wrote:
>> What’s TPE (sorry for asking) and how does it complain exactly?
> Nevermind. This is a false positive and I've reported it to the
> grsecurity people (although they may not fix it...).
> FYI...
> TPE is Trusted Path Execution. Basically, it means that unprivileged
> users can only execute files that are not writable, or in directories
> writable, by users other than the current user or root. This is to help
> make it harder to trick users into executing files written by a
> malicious user.


> However, after thinking about it, I this case is a false positive
> because:
> 1. The /gnu/store/xxx/ directories and all files under them are not
>    group writable and are owned by root.
> 2. /gnu/store has the sticky bit set.
> This means that any files in /gnu/store that are owned by root must have
> "blessed" by root (either linked-in or chowned by root). Therefore, the
> "no group/other writable parent directory" constraint is unnecessary.

Indeed.  The mental model is that /gnu/store is populated by root, on
behalf of other users.  The build users act as a poor way to enforce the
principle of least authority.

>> > 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
> I'm using guix from git and I'll look into it. In my build logs, it
> appears that tar is complaining about an invalid flat ("--sort=name") so
> I think guix is having trouble extracting the substitutes.

I don’t think this is related.

>> 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. 
> ...
>> 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---
> I just did a local experiment (running pstree alongside strace) and,
> unless I'm mistaken, 7519 is running as root.

Hmm, I think you’re right.  In that case the thing does not need to be
world-writable, we should try and check!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]