Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store

DoneSubmitted by YOANN P.
Details
2 participants
  • Ludovic Courtès
  • YOANN P
Owner
unassigned
Severity
normal
Y
Y
YOANN P wrote on 11 Mar 2018 17:08
(name . bug-guix@gnu.org)(address . bug-guix@gnu.org)
DB6P18901MB002262D076C3BE3D6D9BAF16DBDC0@DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM
Hello,

I'm not sure about the reason of this behavior but if configure guix --with-store-dir=/var/tmp/test_guix/gnu/store for exemple, the tests for gettext failed with a permission denied for test-copy-file-1.sh.
If i configure guix with a store to $HOME/.local, everything run smoothly.

Please find attached :

- my guix build script from git for this test
- the test-suite.log

The daemon was launched like this :
------
$ sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild --no-substitutes -c 4 -M 4 --debug
------

The package installation command :
------
$ ./pre-inst-env guix package -i hello --no-grafts --fallback -K
------

The permissions on /var /var/tmp :
------$ stat -c "%a %n" /var /var/tmp755 /var1777 /var/tmp------
If I take a look at the test-copy-file-1.sh, it seems that the /var/tmp is present inside the build chroot cause TMPDIR is defined as /var/tmp instead of /tmp.------$ head -n10 /tmp/guix-build-gettext-minimal-0.19.8.1.drv-0/gettext-0.19.8.1/gettext-tools/gnulib-tests/test-copy-file-1.sh#!/var/tmp/test_guix/gnu/store/sqvi3glr2jzgrvfbj624k1sgs15a954c-bash-minimal-4.4.12/bin/sh
# Test copy-file on the file system of /var/tmp, which usually is a local# file system.
if test -d /var/tmp; then TMPDIR=/var/tmpelse TMPDIR=/tmpfi------
In the "Build Environment Setup" documentation section, there is a mention about /tmp to be writable inside the chroot but there is no mention about /var/tmp and haven't seen a section for /var/tmp chroot inside guix file "build.cc".


Best regards,
Yoann
Attachment: file
Attachment: test-suite.log (.01 MiB)
Attachment: build_guix_from_sources.sh (.00 MiB)
Y
Y
YOANN P wrote on 11 Mar 2018 21:01
(name . 30768@debbugs.gnu.org)(address . 30768@debbugs.gnu.org)
DB6P18901MB0022308B270EB51633D14D13DBDC0@DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM
I've add "/var/tmp" into the chroot directories inside nix/libstore/build.cc with the attached patch (based on v0.14.0 tag) and the installation of gettext and the other dependencies not yet installed seem to finished correctly.

Is there someone who could validate than this patch is correct and is the correct way to solve this problem before i try to submit my the patch mailing list ? :)

Thanks,

Best regards,
Attachment: file
From d879d9fae405131a605860260f034d0d4dcc86e8 Mon Sep 17 00:00:00 2001From: RockAndSka <yoann_mac_donald@hotmail.com>Date: Sun, 11 Mar 2018 20:48:34 +0100Subject: [PATCH] Add writable /var/tmp to chroot
--- nix/libstore/build.cc | 5 +++++ 1 file changed, 5 insertions(+)
Toggle diff (18 lines)diff --git a/nix/libstore/build.cc b/nix/libstore/build.ccindex d68e8b2..ad08b3a 100644--- a/nix/libstore/build.cc+++ b/nix/libstore/build.cc@@ -1849,6 +1849,11 @@ void DerivationGoal::startBuilder() createDirs(chrootTmpDir); chmod_(chrootTmpDir, 01777); + /* Create a writable /var/tmp in the chroot. */+ Path chrootVarTmpDir = chrootRootDir + "/var/tmp";+ createDirs(chrootVarTmpDir);+ chmod_(chrootVarTmpDir, 01777);+ /* Create a /etc/passwd with entries for the build user and the nobody account. The latter is kind of a hack to support Samba-in-QEMU. */-- 2.7.4
L
L
Ludovic Courtès wrote on 12 Mar 2018 14:47
Re: bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store
(name . YOANN P)(address . yoann_mac_donald@hotmail.com)(name . 30768@debbugs.gnu.org)(address . 30768@debbugs.gnu.org)
87y3ixpfrm.fsf@gnu.org
Hello Yoann,
YOANN P <yoann_mac_donald@hotmail.com> skribis:
Toggle quote (11 lines)> --- a/nix/libstore/build.cc> +++ b/nix/libstore/build.cc> @@ -1849,6 +1849,11 @@ void DerivationGoal::startBuilder()> createDirs(chrootTmpDir);> chmod_(chrootTmpDir, 01777);> > + /* Create a writable /var/tmp in the chroot. */> + Path chrootVarTmpDir = chrootRootDir + "/var/tmp";> + createDirs(chrootVarTmpDir);> + chmod_(chrootVarTmpDir, 01777);
We won’t apply this patch because in general there’s no reason for buildprocesses to require /var/tmp (we’ve never encountered that.)
That said, are you sure you want to use--with-store-dir=/var/tmp/xxxxx/gnu/store?
You probably got a ‘configure’ warning already that certain things maynot work, for instance that the shebang max length may be exceeded.
Also using a store other than /gnu/store means you won’t be able to usesubstitutes, nor to compare build results with other machines.
Thanks,Ludo’.
Y
Y
YOANN P wrote on 12 Mar 2018 20:18
RE: bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store
(name . 30768@debbugs.gnu.org)(address . 30768@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
DB6P18901MB00224E575775984DC00D833CDBD30@DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM
Hi Ludovic,
Toggle quote (3 lines)> We won’t apply this patch because in general there’s no reason for build> processes to require /var/tmp (we’ve never encountered that.)
There's always a first time. Since i didn't encounter this behavior with other custom directories than i've tested, looking at the code of the test who failed,i suppose than the store dir is mounted inside the build chroot as itself and is the reason why "/var/tmp" exist during the build with a store dir starting by "/var/tmp".
Despite the fact that generally there’s no reason for build processes to require /var/tmp, is there any risk to add it to the chroot dirs ? If yes (or didn't want to add it), maybe a warning about the fact than we should never use a directory inside "/var/tmp" as store should maybe be add (it will had saving me many hours banging my head) because i've never read somewhere that there was some forbidden directories to use as store and it seems there is some regarding the bug i encounter.
Toggle quote (3 lines)> That said, are you sure you want to use> --with-store-dir=/var/tmp/xxxxx/gnu/store?
Yeah, i'm pretty sure i did want to use this kind of path even if it sounds weird or the reasons are not good. The purpose of my tests was to configure the store with a symlink /var/tmp/guix-[short-hash] who is pointing to a directory where i have the rights. This way, i could use my environment with user X on server A or user Y on server B only by adapting my symlink.
This way, i could achieve a unprivileged portable environment because /var/tmp seems present and writable on all major distribution, plus it seems to work even if /var/tmp is mount with noexec.
Toggle quote (3 lines)> You probably got a ‘configure’ warning already that certain things may> not work, for instance that the shebang max length may be exceeded.
Regarding the warning , i just checked my ./configure log, and there is no warning about the limit length for the store path due to the limit of shebang length, only a warning regarding the substitutes.
Even if i was aware of it after reading Pjotrp notes, i've never found a clear limit after my readings on the web. If Guix Team has an idea of the store path limit lenght, it could be a great idea to add it to the docs or did i missed it ?
Toggle quote (3 lines)> Also using a store other than /gnu/store means you won’t be able to use> substitutes, nor to compare build results with other machines.
I'm pretty aware of that, but having a portable environment who could be used even under unprivileged user without the needing of "proot" / "usernamespace" come with some trade offs and is just a proof of concept even if it is require to build all packages from scratch.
Toggle quote (2 lines)> Thanks,> Ludo’.
Regards,Yoann
L
L
Ludovic Courtès wrote on 12 Mar 2018 22:08
Re: bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store
(name . YOANN P)(address . yoann_mac_donald@hotmail.com)(name . 30768@debbugs.gnu.org)(address . 30768@debbugs.gnu.org)
87vae1knmn.fsf@gnu.org
Hi Yoann,
YOANN P <yoann_mac_donald@hotmail.com> skribis:
Toggle quote (17 lines)>> We won’t apply this patch because in general there’s no reason for build>> processes to require /var/tmp (we’ve never encountered that.)>> There's always a first time. Since i didn't encounter this behavior with other > custom directories than i've tested, looking at the code of the test who failed,> i suppose than the store dir is mounted inside the build chroot as itself and is > the reason why "/var/tmp" exist during the build with a store dir starting by > "/var/tmp".>> Despite the fact that generally there’s no reason for build processes to require > /var/tmp, is there any risk to add it to the chroot dirs ? If yes (or didn't want to > add it), maybe a warning about the fact than we should never use a directory > inside "/var/tmp" as store should maybe be add (it will had saving me many > hours banging my head) because i've never read somewhere that there was > some forbidden directories to use as store and it seems there is some > regarding the bug i encounter.
In general we’re very cautious about changing what goes into the buildenvironment. The daemon provides isolated build environments, andthings will behave differently if we start adding/removing directoriesor files; even simple changes like this can easily hinderreproducibility.
Toggle quote (14 lines)>> That said, are you sure you want to use>> --with-store-dir=/var/tmp/xxxxx/gnu/store?>> Yeah, i'm pretty sure i did want to use this kind of path even if it sounds > weird or the reasons are not good. The purpose of my tests was to > configure the store with a symlink /var/tmp/guix-[short-hash] who is > pointing to a directory where i have the rights. This way, i could use > my environment with user X on server A or user Y on server B only by > adapting my symlink.>> This way, i could achieve a unprivileged portable environment because > /var/tmp seems present and writable on all major distribution, plus it > seems to work even if /var/tmp is mount with noexec.
OK, I see. That’s a worthy goal and a neat hack (I don’t think it’sbeen tried before.)
Toggle quote (12 lines)>> You probably got a ‘configure’ warning already that certain things may>> not work, for instance that the shebang max length may be exceeded.>> Regarding the warning , i just checked my ./configure log, and there is > no warning about the limit length for the store path due to the limit of > shebang length, only a warning regarding the substitutes.>> Even if i was aware of it after reading Pjotrp notes, i've never found a > clear limit after my readings on the web. If Guix Team has an idea of > the store path limit lenght, it could be a great idea to add it to the docs > or did i missed it ?
From m4/guix.m4:
Toggle snippet (8 lines)dnl 'BINPRM_BUF_SIZE' constant in Linux (we leave room for the trailing zero.)dnl The Hurd has a limit of about a page (see exec/hashexec.c.)m4_define([LINUX_HASH_BANG_LIMIT], 127)
dnl Hardcoded 'sun_path' length in <sys/un.h>.m4_define([SOCKET_FILE_NAME_LIMIT], 108)
Toggle quote (8 lines)>> Also using a store other than /gnu/store means you won’t be able to use>> substitutes, nor to compare build results with other machines.>> I'm pretty aware of that, but having a portable environment who could be > used even under unprivileged user without the needing of "proot" / > "usernamespace" come with some trade offs and is just a proof of concept > even if it is require to build all packages from scratch.
Understood.
Are you in a situation where user namespaces are unavailable? HPC?
Thanks,Ludo’.
Y
Y
YOANN P wrote on 14 Mar 2018 00:48
RE: bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store
(name . Ludovic Courtès)(address . ludo@gnu.org)(name . 30768@debbugs.gnu.org)(address . 30768@debbugs.gnu.org)
DB6P18901MB002263FBD187F96096018C7CDBD20@DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM
Hi Ludo,
Toggle quote (28 lines)>Hi Yoann,>>YOANN P <yoann_mac_donald@hotmail.com> skribis:>>>> We won’t apply this patch because in general there’s no reason for build>>> processes to require /var/tmp (we’ve never encountered that.)>>>> There's always a first time. Since i didn't encounter this behavior with other >> custom directories than i've tested, looking at the code of the test who failed,>> i suppose than the store dir is mounted inside the build chroot as itself and is>> the reason why "/var/tmp" exist during the build with a store dir starting by >> "/var/tmp".>>>> Despite the fact that generally there’s no reason for build processes to require>> /var/tmp, is there any risk to add it to the chroot dirs ? If yes (or didn't want to>> add it), maybe a warning about the fact than we should never use a directory >> inside "/var/tmp" as store should maybe be add (it will had saving me many >> hours banging my head) because i've never read somewhere that there was >> some forbidden directories to use as store and it seems there is some >> regarding the bug i encounter.>>In general we’re very cautious about changing what goes into the build>environment.  The daemon provides isolated build environments, and>things will behave differently if we start adding/removing directories>or files; even simple changes like this can easily hinder>reproducibility.>
Indeed.If I keep to persist with my patch applied inside my test env, we'll see if i hit some bug, but i'm pretty sure that your continuous deployment already test if this kind of patch have an impact on the builds.
Toggle quote (18 lines)>>> That said, are you sure you want to use >>> --with-store-dir=/var/tmp/xxxxx/gnu/store?>>>> Yeah, i'm pretty sure i did want to use this kind of path even if it sounds >> weird or the reasons are not good. The purpose of my tests was to >> configure the store with a symlink /var/tmp/guix-[short-hash] who is >> pointing to a directory where i have the rights. This way, i could use >> my environment with user X on server A or user Y on server B only by >> adapting my symlink.>>>> This way, i could achieve a unprivileged portable environment because >> /var/tmp seems present and writable on all major distribution, plus it >> seems to work even if /var/tmp is mount with noexec.>>OK, I see.  That’s a worthy goal and a neat hack (I don’t think it’s>been tried before.)>
Maybe if it hasn't test before, there was a good reason ;)Like the fact I wasn't aware of this kind of patch who seems to prevent the daemon to access directly the store via a direct symlink but require to symlink the upper directory.https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Symlink_Protection
Toggle quote (24 lines)>>> You probably got a ‘configure’ warning already that certain things may>>> not work, for instance that the shebang max length may be exceeded.>>>> Regarding the warning , i just checked my ./configure log, and there is >> no warning about the limit length for the store path due to the limit of >> shebang length, only a warning regarding the substitutes.>>>> Even if i was aware of it after reading Pjotrp notes, i've never found a >> clear limit after my readings on the web. If Guix Team has an idea of >> the store path limit lenght, it could be a great idea to add it to the docs >> or did i missed it ?>>From m4/guix.m4:>>--8<---------------cut here---------------start------------->8--->dnl 'BINPRM_BUF_SIZE' constant in Linux (we leave room for the trailing zero.)>dnl The Hurd has a limit of about a page (see exec/hashexec.c.)>m4_define([LINUX_HASH_BANG_LIMIT], 127)>>dnl Hardcoded 'sun_path' length in <sys/un.h>.>m4_define([SOCKET_FILE_NAME_LIMIT], 108)>--8<---------------cut here---------------end--------------->8--->
Hum, i'm not sure this part of code answer my question :)Are we agreed than LINUX_HASH_BANG_LIMIT is the max number of char for a shebang and SOCKET_FILE_NAME_LIMIT is only the limit for the socket file name ?
What i was asking is the maximum lenght for the store path regarding the fact (if i am not wrong) than a shebang inside guix is compose like this :
[store_path]/[build_hash]-[program_name]-[program_version]/bin/[program_name]
- is there a convention who defined the maximum lenght of a program version string ? (1.1.1, 1.1.1-rc1, 1.1.1-beta)
- is there a convention who defined the maximum lenght of a program name ?
I think than if there is no limit for those two strings inside the store, we can't exactly know the maximum lenght for the store path but maybe you have a quick way to lookup at the maximum lenght for thoses two strings in all guix builds ?
Toggle quote (12 lines)>>> Also using a store other than /gnu/store means you won’t be able to use>>> substitutes, nor to compare build results with other machines.>>>> I'm pretty aware of that, but having a portable environment who could be >> used even under unprivileged user without the needing of "proot" / >> "usernamespace" come with some trade offs and is just a proof of concept >> even if it is require to build all packages from scratch.>>Understood.>>Are you in a situation where user namespaces are unavailable?  HPC?
Not at all, i was just playing with Guix to see if it can fulfill my long desires to have an easy unprivileged portable environment due to old habits to intervene into some hostiles environments in my previous job.
The need to use "proot" / "usernamespace" keep the huge benefit that is the use of substitutes but require to rewrite all commands present inside the profile.I had first thinked to try to write a guix-wrapper who create small launchers for binaries found inside a profile and add the directory containing the launchers in PATH but paused this idea because i didn't find yet how you could easily fully bind "/" (read-only) inside NS , but overwrite some specific files and directories like a docker container (need to test bubblewrap, Proot seems to be able to achieve it).
i'll try to re-think about scripting a launcher generator soon, because i think it is by far a better option than my hat trick with /var/tmp :)
Toggle quote (4 lines)>>Thanks,>Ludo’.
Regards,Yoann
L
L
Ludovic Courtès wrote on 14 Mar 2018 10:33
Re: bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store
(name . YOANN P)(address . yoann_mac_donald@hotmail.com)(name . 30768@debbugs.gnu.org)(address . 30768@debbugs.gnu.org)
87bmfrypa8.fsf@gnu.org
Hello,
YOANN P <yoann_mac_donald@hotmail.com> skribis:
Toggle quote (2 lines)>>YOANN P <yoann_mac_donald@hotmail.com> skribis:
[...]
Toggle quote (21 lines)>>> Even if i was aware of it after reading Pjotrp notes, i've never found a >>> clear limit after my readings on the web. If Guix Team has an idea of >>> the store path limit lenght, it could be a great idea to add it to the docs >>> or did i missed it ?>>>>From m4/guix.m4:>>>>--8<---------------cut here---------------start------------->8--->>dnl 'BINPRM_BUF_SIZE' constant in Linux (we leave room for the trailing zero.)>>dnl The Hurd has a limit of about a page (see exec/hashexec.c.)>>m4_define([LINUX_HASH_BANG_LIMIT], 127)>>>>dnl Hardcoded 'sun_path' length in <sys/un.h>.>>m4_define([SOCKET_FILE_NAME_LIMIT], 108)>>--8<---------------cut here---------------end--------------->8--->>>> Hum, i'm not sure this part of code answer my question :)> Are we agreed than LINUX_HASH_BANG_LIMIT is the max number of char for a > shebang and SOCKET_FILE_NAME_LIMIT is only the limit for the socket file name ?
Yes.
Toggle quote (3 lines)> What i was asking is the maximum lenght for the store path regarding the fact > (if i am not wrong) than a shebang inside guix is compose like this :
The only limit here is PATH_MAX.
Toggle quote (6 lines)>>Are you in a situation where user namespaces are unavailable?  HPC?>> Not at all, i was just playing with Guix to see if it can fulfill my long desires to have > an easy unprivileged portable environment due to old habits to intervene into some > hostiles environments in my previous job.
Then I strongly recommend using it as documented, i.e., using /gnu/storeas the store and running guix-daemon as root.
You can’t really get around it:
https://guix-hpc.bordeaux.inria.fr/blog/2017/09/reproducibility-and-root-privileges/
Thanks,Ludo’.
L
L
Ludovic Courtès wrote on 15 Mar 2018 10:31
control message for bug #30768
(address . control@debbugs.gnu.org)
873711wuqm.fsf@gnu.org
tags 30768 wontfixclose 30768
?
Your comment

This issue is archived.

To comment on this conversation send email to 30768@debbugs.gnu.org