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/tmp
755 /var
1777 /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/tmp
else
TMPDIR=/tmp
fi
------

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 2001
From: RockAndSka <yoann_mac_donald@hotmail.com>
Date: Sun, 11 Mar 2018 20:48:34 +0100
Subject: [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.cc
index 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 build
processes 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 may
not 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 use
substitutes, 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 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.

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’s
been 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.

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/store
as the store and running guix-daemon as root.

You can’t really get around it:


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 wontfix
close 30768
?
Your comment

This issue is archived.

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