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

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

[YOANN P]

[-- Attachment #1.1: Type: text/plain, Size: 1636 bytes --]

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 #1.2: Type: text/html, Size: 7342 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: test-suite.log --]
[-- Type: text/x-log; name="test-suite.log", Size: 5589 bytes --]

=========================================================
   gettext-tools 0.19.8.1: gnulib-tests/test-suite.log
=========================================================

# TOTAL: 198
# PASS:  170
# SKIP:  27
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

SKIP: test-set-mode-acl.sh
==========================

+ test 0 = 0
+ echo 'Skipping test: insufficient ACL support'
Skipping test: insufficient ACL support
+ exit 77
SKIP test-set-mode-acl.sh (exit status: 77)

SKIP: test-set-mode-acl-1.sh
============================

+ test 0 = 0
+ echo 'Skipping test: insufficient ACL support'
Skipping test: insufficient ACL support
+ exit 77
SKIP test-set-mode-acl-1.sh (exit status: 77)

SKIP: test-set-mode-acl-2.sh
============================

+ test 0 = 0
+ echo 'Skipping test: insufficient ACL support'
Skipping test: insufficient ACL support
+ exit 77
SKIP test-set-mode-acl-2.sh (exit status: 77)

SKIP: test-copy-acl.sh
======================

+ test 0 = 0
+ echo 'Skipping test: insufficient ACL support'
Skipping test: insufficient ACL support
+ exit 77
SKIP test-copy-acl.sh (exit status: 77)

SKIP: test-copy-acl-1.sh
========================

+ test 0 = 0
+ echo 'Skipping test: insufficient ACL support'
Skipping test: insufficient ACL support
+ exit 77
SKIP test-copy-acl-1.sh (exit status: 77)

SKIP: test-copy-acl-2.sh
========================

+ test 0 = 0
+ echo 'Skipping test: insufficient ACL support'
Skipping test: insufficient ACL support
+ exit 77
SKIP test-copy-acl-2.sh (exit status: 77)

SKIP: test-btowc1.sh
====================

Skipping test: no traditional french locale is supported
SKIP test-btowc1.sh (exit status: 77)

FAIL: test-copy-file-1.sh
=========================

+ func_tmpdir
+ : /var/tmp
+ tmp=
+ tmp=/var/tmp/gl22304-6410
+ umask 077
+ mkdir /var/tmp/gl22304-6410
mkdir: cannot create directory '/var/tmp/gl22304-6410': Permission denied
+ echo './test-copy-file.sh: cannot create a temporary directory in /var/tmp'
./test-copy-file.sh: cannot create a temporary directory in /var/tmp
+ exit 1
+ func_tmpdir
+ : /var/tmp
+ tmp=
+ tmp=/var/tmp/gl22319-17960
+ umask 077
+ mkdir /var/tmp/gl22319-17960
mkdir: cannot create directory '/var/tmp/gl22319-17960': Permission denied
+ echo './test-copy-file.sh: cannot create a temporary directory in /var/tmp'
./test-copy-file.sh: cannot create a temporary directory in /var/tmp
+ exit 1
FAIL test-copy-file-1.sh (exit status: 1)

SKIP: test-file-has-acl.sh
==========================

+ test 0 = 0
+ echo 'Skipping test: insufficient ACL support'
Skipping test: insufficient ACL support
+ exit 77
SKIP test-file-has-acl.sh (exit status: 77)

SKIP: test-file-has-acl-1.sh
============================

+ test 0 = 0
+ echo 'Skipping test: insufficient ACL support'
Skipping test: insufficient ACL support
+ exit 77
SKIP test-file-has-acl-1.sh (exit status: 77)

SKIP: test-file-has-acl-2.sh
============================

+ test 0 = 0
+ echo 'Skipping test: insufficient ACL support'
Skipping test: insufficient ACL support
+ exit 77
SKIP test-file-has-acl-2.sh (exit status: 77)

SKIP: test-mbrtowc1.sh
======================

Skipping test: no traditional french locale is supported
SKIP test-mbrtowc1.sh (exit status: 77)

SKIP: test-mbrtowc3.sh
======================

Skipping test: no traditional japanese locale is supported
SKIP test-mbrtowc3.sh (exit status: 77)

SKIP: test-mbrtowc4.sh
======================

Skipping test: no transitional chinese locale is supported
SKIP test-mbrtowc4.sh (exit status: 77)

SKIP: test-mbrtowc-w32-1.sh
===========================

Skipping test: not a native Windows system
SKIP test-mbrtowc-w32-1.sh (exit status: 77)

SKIP: test-mbrtowc-w32-2.sh
===========================

Skipping test: not a native Windows system
SKIP test-mbrtowc-w32-2.sh (exit status: 77)

SKIP: test-mbrtowc-w32-3.sh
===========================

Skipping test: not a native Windows system
SKIP test-mbrtowc-w32-3.sh (exit status: 77)

SKIP: test-mbrtowc-w32-4.sh
===========================

Skipping test: not a native Windows system
SKIP test-mbrtowc-w32-4.sh (exit status: 77)

SKIP: test-mbrtowc-w32-5.sh
===========================

Skipping test: not a native Windows system
SKIP test-mbrtowc-w32-5.sh (exit status: 77)

SKIP: test-mbsrtowcs1.sh
========================

Skipping test: no traditional french locale is supported
SKIP test-mbsrtowcs1.sh (exit status: 77)

SKIP: test-mbsrtowcs3.sh
========================

Skipping test: no traditional japanese locale is supported
SKIP test-mbsrtowcs3.sh (exit status: 77)

SKIP: test-mbsrtowcs4.sh
========================

Skipping test: no transitional chinese locale is supported
SKIP test-mbsrtowcs4.sh (exit status: 77)

SKIP: test-mbsstr3.sh
=====================

Skipping test: no chinese GB18030 locale is supported
SKIP test-mbsstr3.sh (exit status: 77)

SKIP: test-wcrtomb-w32-1.sh
===========================

Skipping test: not a native Windows system
SKIP test-wcrtomb-w32-1.sh (exit status: 77)

SKIP: test-wcrtomb-w32-2.sh
===========================

Skipping test: not a native Windows system
SKIP test-wcrtomb-w32-2.sh (exit status: 77)

SKIP: test-wcrtomb-w32-3.sh
===========================

Skipping test: not a native Windows system
SKIP test-wcrtomb-w32-3.sh (exit status: 77)

SKIP: test-wcrtomb-w32-4.sh
===========================

Skipping test: not a native Windows system
SKIP test-wcrtomb-w32-4.sh (exit status: 77)

SKIP: test-wcrtomb-w32-5.sh
===========================

Skipping test: not a native Windows system
SKIP test-wcrtomb-w32-5.sh (exit status: 77)


[-- Attachment #3: build_guix_from_sources.sh --]
[-- Type: application/x-shellscript, Size: 1241 bytes --]

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

[YOANN P]

[-- Attachment #1.1: Type: text/plain, Size: 429 bytes --]

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 #1.2: Type: text/html, Size: 1330 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-writable-var-tmp-to-chroot.patch --]
[-- Type: text/x-patch; name="0001-Add-writable-var-tmp-to-chroot.patch", Size: 938 bytes --]

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(+)

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

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

[Ludovic Courtès]

Hello Yoann,

YOANN P <yoann_mac_donald@hotmail.com> skribis:

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

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

[YOANN P]

Hi Ludovic,

> 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.

> 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.

> 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 ?

> 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.

> Thanks,
> Ludo’.
 
Regards,
Yoann

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

[Ludovic Courtès]

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.

>> 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.)

>> 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---

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

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

[YOANN P]

Hi Ludo,

>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.

>>> 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

>>> 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 ?

>>> 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 :)

>
>Thanks,
>Ludo’.

Regards,
Yoann

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

[Ludovic Courtès]

Hello,

YOANN P <yoann_mac_donald@hotmail.com> skribis:

>>YOANN P <yoann_mac_donald@hotmail.com> skribis:

[...]

>>> 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.

> 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.

>>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:

  https://guix-hpc.bordeaux.inria.fr/blog/2017/09/reproducibility-and-root-privileges/

Thanks,
Ludo’.