From mboxrd@z Thu Jan 1 00:00:00 1970 From: "pelzflorian (Florian Pelz)" Subject: bug#35662: Really relocatable binaries crash with Permission denied Date: Tue, 14 May 2019 23:04:53 +0200 Message-ID: <20190514210453.2p7x3ibpgohwaxot@pelzflorian.localdomain> References: <87o94ax9lw.fsf@gnu.org> <20190511050518.ozmvhsov6meg6g5f@pelzflorian.localdomain> <87ftpivlnv.fsf@gnu.org> <20190513103440.xkri3uk2oxtk4rn6@pelzflorian.localdomain> <87r292qx30.fsf@gnu.org> <20190513151736.ffbuofr3vmyqaoov@pelzflorian.localdomain> <87tvdyozra.fsf@gnu.org> <20190513204524.ozcnp6faamrbfkcv@pelzflorian.localdomain> <20190514080525.xspgsob6payn2ioa@pelzflorian.localdomain> <87h89wydf7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([209.51.188.92]:41012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQech-0005DD-Sd for bug-guix@gnu.org; Tue, 14 May 2019 17:06:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hQecf-000255-M0 for bug-guix@gnu.org; Tue, 14 May 2019 17:06:07 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:36501) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hQecc-00020Q-6U for bug-guix@gnu.org; Tue, 14 May 2019 17:06:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hQecb-0005Vn-Uy for bug-guix@gnu.org; Tue, 14 May 2019 17:06:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: Content-Disposition: inline In-Reply-To: <87h89wydf7.fsf@gnu.org> 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: 35662@debbugs.gnu.org On Tue, May 14, 2019 at 10:43:56PM +0200, Ludovic Courtès wrote: > "pelzflorian (Florian Pelz)" skribis: > > > On Mon, May 13, 2019 at 10:45:24PM +0200, pelzflorian (Florian Pelz) wrote: > >> On Mon, May 13, 2019 at 10:39:21PM +0200, Ludovic Courtès wrote: > >> > I suspect ZFS-on-Linux (right?) is doing something unusual here: > >> > >> I suppose it is ZFS on Linux; it is Linux, I can ask the admins if it > >> could be something else. > >> > > > > The admins have confirmed that they use “Proxmox on ZFS” (judging from > > it is ZFS on Linux) and > > they have confirmed that they have disabled user namespaces in their > > Proxmox settings. > > User namespaces are orthogonal to file systems, but anyway it looks like > ZFS is refusing to let us do these things. > Do I understand correctly that user namespaces are not really disabled (?) but fail on ZFS? This seems strange, but a Web search for “zfs user namespaces” shows other people having trouble with this combination. The admins told me they had to disable user namespaces because it caused some kind of trouble. > I don’t have any great option to offer. You could perhaps modify > run-in-namespace.c so that it doesn’t even try user namespaces and > instead goes directly to the PRoot option? > > However working around this behavior of ZFS it not completely trivial > and I’m not sure we should put much energy to paper over non-standard > file system behavior. > > Thoughts? > If ZFS makes user namespaces fail, then could run-un-namespace.c fall back to PRoot when detecting ZFS, somehow? Regards, Florian