bug#35662: Really relocatable binaries crash with Permission denied

[pelzflorian (Florian Pelz)]

On Tue, May 14, 2019 at 10:43:56PM +0200, Ludovic Courtès wrote:
> "pelzflorian (Florian Pelz)" <address@hidden> 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
> > <https://pve.proxmox.com/wiki/ZFS_on_Linux> 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