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
?
Your comment

This issue is archived.

To comment on this conversation send an email to 59185@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 59185
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch