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 <address@hidden> 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