bug#59185: Trouble mounting recursive file systems in containers

bug#59185: Trouble mounting recursive file systems in containers

[Morgan Smith]

Hello!

So I was trying to mount /run/user/1000 in a container so it would have
access to all my wayland sockets and such when I got a very cryptic
error message.

I was trying something like this:

guix shell --share=/run/user/1000 -C coreutils

After far too long tracking down the issue, it turns out that the
directory had submounts within it meaning that the MS_REC flag is
required to bind mount it.

My /run/user/1000 only had a submount because xdg-document-portal was
making one.  To test this yourself you can run `mount` to find something
with some submounts.  I think /sys/fs might fail for me for the same
reason.

Now I have no clue what we should do to enable this use case.  Maybe we
should allow users to specify mount options using something like this?

guix shell -C --mount=rbind,ro=/run/user/1000

Maybe we could always bind with the recursive flag?


Thanks,

Morgan

bug#59185: Trouble mounting recursive file systems in containers

[Ricardo Wurmus]

[-- Attachment #1: Type: text/plain, Size: 248 bytes --]

Hi Morgan,

yes, mounting with MS_REC seems sensible.  Not mounting with MS_REC is
also responsible for a couple of errors e.g. when trying to map / inside
the container (when / has other bind mounts).

Here’s a patch that works for me:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-WIP.patch --]
[-- Type: text/x-patch, Size: 1491 bytes --]

From 806969ad86038052bf4d0dd2755617beaaa33cb6 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus <rekado@elephly.net>
Date: Sat, 19 Nov 2022 23:16:52 +0100
Subject: [PATCH] WIP

---
 gnu/build/file-systems.scm | 2 +-
 guix/build/syscalls.scm    | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/gnu/build/file-systems.scm b/gnu/build/file-systems.scm
index 15b8f73312..66ca22d6ea 100644
--- a/gnu/build/file-systems.scm
+++ b/gnu/build/file-systems.scm
@@ -1127,7 +1127,7 @@ (define (mount-flags->bit-mask flags)
       (('read-only rest ...)
        (logior MS_RDONLY (loop rest)))
       (('bind-mount rest ...)
-       (logior MS_BIND (loop rest)))
+       (logior MS_REC (logior MS_BIND (loop rest))))
       (('no-suid rest ...)
        (logior MS_NOSUID (loop rest)))
       (('no-dev rest ...)
diff --git a/guix/build/syscalls.scm b/guix/build/syscalls.scm
index 61926beb80..2a12567b15 100644
--- a/guix/build/syscalls.scm
+++ b/guix/build/syscalls.scm
@@ -51,6 +51,7 @@ (define-module (guix build syscalls)
             MS_RELATIME
             MS_BIND
             MS_MOVE
+            MS_REC
             MS_SHARED
             MS_LAZYTIME
             MNT_FORCE
@@ -541,6 +542,7 @@ (define MS_NOATIME         1024)
 (define MS_NODIRATIME      2048)
 (define MS_BIND            4096)
 (define MS_MOVE            8192)
+(define MS_REC            16384)
 (define MS_SHARED       1048576)
 (define MS_RELATIME     2097152)
 (define MS_STRICTATIME 16777216)
-- 
2.36.1


[-- Attachment #3: Type: text/plain, Size: 14 bytes --]



-- 
Ricardo

bug#59185: Trouble mounting recursive file systems in containers

[Ludovic Courtès]

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

> yes, mounting with MS_REC seems sensible.  Not mounting with MS_REC is
> also responsible for a couple of errors e.g. when trying to map / inside
> the container (when / has other bind mounts).

Having reread mount(2), bind-mounting with MS_REC by default seems like
a reasonable choice, indeed.

Ludo’.

bug#59185: Trouble mounting recursive file systems in containers

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> yes, mounting with MS_REC seems sensible.  Not mounting with MS_REC is
>> also responsible for a couple of errors e.g. when trying to map / inside
>> the container (when / has other bind mounts).
>
> Having reread mount(2), bind-mounting with MS_REC by default seems like
> a reasonable choice, indeed.

Great.  I’ve pushed this with commit c585b4bc68813a351d6a87d19b9adf4041506355.

-- 
Ricardo