* bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store @ 2018-03-11 16:08 YOANN P 2018-03-11 20:01 ` YOANN P 0 siblings, 1 reply; 7+ messages in thread From: YOANN P @ 2018-03-11 16:08 UTC (permalink / raw) To: 30768 [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store 2018-03-11 16:08 bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store YOANN P @ 2018-03-11 20:01 ` YOANN P 2018-03-12 13:47 ` Ludovic Courtès 0 siblings, 1 reply; 7+ messages in thread From: YOANN P @ 2018-03-11 20:01 UTC (permalink / raw) To: 30768@debbugs.gnu.org [-- 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store 2018-03-11 20:01 ` YOANN P @ 2018-03-12 13:47 ` Ludovic Courtès 2018-03-12 19:18 ` YOANN P 0 siblings, 1 reply; 7+ messages in thread From: Ludovic Courtès @ 2018-03-12 13:47 UTC (permalink / raw) To: YOANN P; +Cc: 30768@debbugs.gnu.org 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’. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store 2018-03-12 13:47 ` Ludovic Courtès @ 2018-03-12 19:18 ` YOANN P 2018-03-12 21:08 ` Ludovic Courtès 0 siblings, 1 reply; 7+ messages in thread From: YOANN P @ 2018-03-12 19:18 UTC (permalink / raw) To: 30768@debbugs.gnu.org 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store 2018-03-12 19:18 ` YOANN P @ 2018-03-12 21:08 ` Ludovic Courtès 2018-03-13 23:48 ` YOANN P 0 siblings, 1 reply; 7+ messages in thread From: Ludovic Courtès @ 2018-03-12 21:08 UTC (permalink / raw) To: YOANN P; +Cc: 30768@debbugs.gnu.org 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’. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store 2018-03-12 21:08 ` Ludovic Courtès @ 2018-03-13 23:48 ` YOANN P 2018-03-14 9:33 ` Ludovic Courtès 0 siblings, 1 reply; 7+ messages in thread From: YOANN P @ 2018-03-13 23:48 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 30768@debbugs.gnu.org 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store 2018-03-13 23:48 ` YOANN P @ 2018-03-14 9:33 ` Ludovic Courtès 0 siblings, 0 replies; 7+ messages in thread From: Ludovic Courtès @ 2018-03-14 9:33 UTC (permalink / raw) To: YOANN P; +Cc: 30768@debbugs.gnu.org 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’. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-03-14 9:34 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-03-11 16:08 bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store YOANN P 2018-03-11 20:01 ` YOANN P 2018-03-12 13:47 ` Ludovic Courtès 2018-03-12 19:18 ` YOANN P 2018-03-12 21:08 ` Ludovic Courtès 2018-03-13 23:48 ` YOANN P 2018-03-14 9:33 ` Ludovic Courtès
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.