From mboxrd@z Thu Jan 1 00:00:00 1970 From: YOANN P Subject: bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store Date: Tue, 13 Mar 2018 23:48:54 +0000 Message-ID: References: <87y3ixpfrm.fsf@gnu.org> , <87vae1knmn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1evtgE-0001IY-Rn for bug-guix@gnu.org; Tue, 13 Mar 2018 19:50:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1evtgA-0000O6-U1 for bug-guix@gnu.org; Tue, 13 Mar 2018 19:50:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:52249) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1evtgA-0000Ny-Pk for bug-guix@gnu.org; Tue, 13 Mar 2018 19:50:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1evtgA-0005Fz-DT for bug-guix@gnu.org; Tue, 13 Mar 2018 19:50:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87vae1knmn.fsf@gnu.org> Content-Language: fr-FR List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: "30768@debbugs.gnu.org" <30768@debbugs.gnu.org> Hi Ludo, >Hi Yoann, > >YOANN P skribis: > >>> We won=92t apply this patch because in general there=92s no reason for = build >>> processes to require /var/tmp (we=92ve never encountered that.) >> >> There's always a first time. Since i didn't encounter this behavior with= other=20 >> 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 itsel= f and is >> the reason why "/var/tmp" exist during the build with a store dir starti= ng by=20 >> "/var/tmp". >> >> Despite the fact that generally there=92s no reason for build processes = to require >> /var/tmp, is there any risk to add it to the chroot dirs ? If yes (or di= dn't want to >> add it), maybe a warning about the fact than we should never use a direc= tory=20 >> inside "/var/tmp" as store should maybe be add (it will had saving me ma= ny=20 >> hours banging my head) because i've never read somewhere that there was= =20 >> some forbidden directories to use as store and it seems there is some=20 >> regarding the bug i encounter. > >In general we=92re very cautious about changing what goes into the build >environment.=A0 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= =20 i hit some bug, but i'm pretty sure that your continuous deployment already= =20 test if this kind of patch have an impact on the builds. >>> That said, are you sure you want to use=20 >>> --with-store-dir=3D/var/tmp/xxxxx/gnu/store? >> >> Yeah, i'm pretty sure i did want to use this kind of path even if it sou= nds=20 >> weird or the reasons are not good. The purpose of my tests was to=20 >> configure the store with a symlink /var/tmp/guix-[short-hash] who is=20 >> pointing to a directory where i have the rights. This way, i could use=20 >> my environment with user X on server A or user Y on server B only by=20 >> adapting my symlink. >> >> This way, i could achieve a unprivileged portable environment because=20 >> /var/tmp seems present and writable on all major distribution, plus it=20 >> seems to work even if /var/tmp is mount with noexec. > >OK, I see.=A0 That=92s a worthy goal and a neat hack (I don=92t think it= =92s >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= =20 daemon to access directly the store via a direct symlink but require to sym= link=20 the upper directory. https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Symlink_Protec= tion >>> You probably got a =91configure=92 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= =20 >> no warning about the limit length for the store path due to the limit of= =20 >> shebang length, only a warning regarding the substitutes. >> >> Even if i was aware of it after reading Pjotrp notes, i've never found a= =20 >> clear limit after my readings on the web. If Guix Team has an idea of=20 >> the store path limit lenght, it could be a great idea to add it to the d= ocs=20 >> 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 ze= ro.) >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 . >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=20 shebang and SOCKET_FILE_NAME_LIMIT is only the limit for the socket file na= me ? What i was asking is the maximum lenght for the store path regarding the fa= ct=20 (if i am not wrong) than a shebang inside guix is compose like this : [store_path]/[build_hash]-[program_name]-[program_version]/bin/[program_nam= e] - is there a convention who defined the maximum lenght of a program version= string ?=20 (1.1.1, 1.1.1-rc1, 1.1.1-beta) - is there a convention who defined the maximum lenght of a program name ?= =20 I think than if there is no limit for those two strings inside the store, w= e can't exactly know=20 the maximum lenght for the store path but maybe you have a quick way to loo= kup at=20 the maximum lenght for thoses two strings in all guix builds ? >>> Also using a store other than /gnu/store means you won=92t be able to u= se >>> substitutes, nor to compare build results with other machines. >> >> I'm pretty aware of that, but having a portable environment who could be= =20 >> used even under unprivileged user without the needing of "proot" /=20 >> "usernamespace" come with some trade offs and is just a proof of concept= =20 >> even if it is require to build all packages from scratch. > >Understood. > >Are you in a situation where user namespaces are unavailable?=A0 HPC? Not at all, i was just playing with Guix to see if it can fulfill my long d= esires to have=20 an easy unprivileged portable environment due to old habits to intervene in= to some=20 hostiles environments in my previous job. The need to use "proot" / "usernamespace" keep the huge benefit that is the= use of=20 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 launche= rs for binaries=20 found inside a profile and add the directory containing the launchers in PA= TH but paused=20 this idea because i didn't find yet how you could easily fully bind "/" (re= ad-only) inside NS , but=20 overwrite some specific files and directories like a docker container (need= to test=20 bubblewrap, Proot seems to be able to achieve it). i'll try to re-think about scripting a launcher generator soon, because i t= hink it is by far a=20 better option than my hat trick with /var/tmp :) > >Thanks, >Ludo=92. Regards, Yoann=