bug#41499: /proc/filesystems impurity in build environment

[Ludovic Courtès]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> skribis:

> The Linux kernel's /proc/filesystems is an impurity in the Guix build
> environment.  Its contents can cause the same derivation to behave
> differently on different systems.
>
> For example, the default kernel on Fedora systems uses SELinux, so
> /proc/filesystems contains "selinuxfs".  However, the default kernel on
> Guix System does not use SELinux, so /proc/filesystems does not contain
> "selinuxfs".  This causes the sed derivation to fail when run on Fedora,
> but not on Guix System:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41498
>
> Can we avoid this problem somehow?  For example, is there a way to
> normalize /proc/filesystems in the build environment?
>
> We have the --impersonate-linux-2.6 option as a way to eliminate a
> similar kind of impurity, but that option doesn't actually change the
> contents of /proc/filesystems at all.  I tried it.

The daemon mounts /proc in the build environment (see
libstore/build.cc):

    /* Bind a new instance of procfs on /proc to reflect our
       private PID namespace. */
    createDirs(chrootRootDir + "/proc");
    if (mount("none", (chrootRootDir + "/proc").c_str(), "proc", 0, 0) == -1)
        throw SysError("mounting /proc");

/proc is needed for many things on GNU/Linux.  For example, libc’s
loader relies on /proc/self/exe to implement $ORIGIN, ‘getlogin_r’
relies on /proc/self/loginuid, ‘ttyname’ uses /proc/self/fd, ‘sysconf’
uses /proc/sys/kernel, etc.  So we have to have /proc in there.

The problem is that /proc appears to be all-or-nothing.

What we could do maybe is bind-mount our own statically-defined
‘filesystems’ file on top of the procfs mount above.

There would still be many leaks in /proc anyway, so perhaps a better
approach is to patch ‘sed’ to not refer to it.

Thoughts?

Ludo’.