From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store Date: Mon, 12 Mar 2018 22:08:48 +0100 Message-ID: <87vae1knmn.fsf@gnu.org> References: <87y3ixpfrm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56415) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1evUhp-0000cz-K1 for bug-guix@gnu.org; Mon, 12 Mar 2018 17:10:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1evUhm-0003Gs-CX for bug-guix@gnu.org; Mon, 12 Mar 2018 17:10:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:49666) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1evUhm-0003Go-7V for bug-guix@gnu.org; Mon, 12 Mar 2018 17:10:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1evUhm-0003ez-2N for bug-guix@gnu.org; Mon, 12 Mar 2018 17:10:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: (YOANN P.'s message of "Mon, 12 Mar 2018 19:18:24 +0000") 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: YOANN P Cc: "30768@debbugs.gnu.org" <30768@debbugs.gnu.org> Hi Yoann, YOANN P skribis: >> We won=E2=80=99t apply this patch because in general there=E2=80=99s no = reason for build >> processes to require /var/tmp (we=E2=80=99ve 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 itself= and is=20 > the reason why "/var/tmp" exist during the build with a store dir startin= g by=20 > "/var/tmp". > > Despite the fact that generally there=E2=80=99s no reason for build proce= sses to require=20 > /var/tmp, is there any risk to add it to the chroot dirs ? If yes (or did= n't want to=20 > add it), maybe a warning about the fact than we should never use a direct= ory=20 > inside "/var/tmp" as store should maybe be add (it will had saving me man= y=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=E2=80=99re very cautious about changing what goes into the bu= ild 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=3D/var/tmp/xxxxx/gnu/store? > > Yeah, i'm pretty sure i did want to use this kind of path even if it soun= ds=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. That=E2=80=99s a worthy goal and a neat hack (I don=E2=80=99t t= hink it=E2=80=99s been tried before.) >> You probably got a =E2=80=98configure=E2=80=99 warning already that cert= ain 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 do= cs=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 zer= o.) 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--- >> Also using a store other than /gnu/store means you won=E2=80=99t 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= =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? HPC? Thanks, Ludo=E2=80=99.