Trouble mounting recursive file systems in containers

  • Done
  • quality assurance status badge
Details
3 participants
  • Morgan Smith
  • Ludovic Courtès
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Morgan Smith
Severity
normal
M
M
Morgan Smith wrote on 10 Nov 2022 23:35
(address . bug-guix@gnu.org)
DM5PR03MB3163DEB54D1EC8C8B435BD13C5019@DM5PR03MB3163.namprd03.prod.outlook.com
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
R
R
Ricardo Wurmus wrote on 19 Nov 2022 23:23
(address . 59185@debbugs.gnu.org)
87cz9ishur.fsf@elephly.net
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:
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(-)

Toggle diff (35 lines)
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
--
Ricardo
L
L
Ludovic Courtès wrote on 19 Nov 2022 23:29
(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 59185@debbugs.gnu.org)
8735ae8toc.fsf@gnu.org
Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

Toggle quote (4 lines)
> 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’.
R
R
Ricardo Wurmus wrote on 20 Nov 2022 21:35
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 59185-done@debbugs.gnu.org)
874juts6s8.fsf@elephly.net
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (9 lines)
> 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
Closed
?