Hi Chris, Chris Marusich <[email protected]> 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’.
