[PATCH] environment: container: Do not remount network files as read-only.

[PATCH] environment: container: Do not remount network files as read-only.

[Thompson, David]

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

I noticed that 'guix environment --container --network' didn't work on
an Ubuntu machine I was on, and the culprit was remounting things like
/etc/resolv.conf read-only after the initial bind mount.

What do y'all think?

Thanks,

- Dave

[-- Attachment #2: 0001-environment-container-Do-not-remount-network-files-a.patch --]
[-- Type: text/x-patch, Size: 1629 bytes --]

From 9820a937ef5ab6793f2495a1ce50ff14abb6ec7c Mon Sep 17 00:00:00 2001
From: David Thompson <dthompson@vistahigherlearning.com>
Date: Thu, 17 Mar 2016 14:01:19 -0400
Subject: [PATCH] environment: container: Do not remount network files as
 read-only.

* gnu/scripts/environment.scm (launch-environment/container): Make
  network mappings writable.
---
 guix/scripts/environment.scm | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index b122b4c..896804b 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -391,7 +391,13 @@ host file systems to mount inside the container."
                                             (file-system-mapping
                                              (source file)
                                              (target file)
-                                             (writable? #f))))
+                                             ;; An unpriviliged user might not
+                                             ;; be able to remount
+                                             ;; /etc/resolv.conf as read-only,
+                                             ;; so we say that it is writable
+                                             ;; here, even though in practice
+                                             ;; it is not.
+                                             (writable? #t))))
                                      %network-configuration-files)
                          '())
                      ;; Mappings for the union closure of all inputs.
-- 
2.6.3

Re: [PATCH] environment: container: Do not remount network files as read-only.

[Ludovic Courtès]

"Thompson, David" <dthompson2@worcester.edu> skribis:

> I noticed that 'guix environment --container --network' didn't work on
> an Ubuntu machine I was on, and the culprit was remounting things like
> /etc/resolv.conf read-only after the initial bind mount.

[...]

>                                              (file-system-mapping
>                                               (source file)
>                                               (target file)
> -                                             (writable? #f))))
> +                                             ;; An unpriviliged user might not
> +                                             ;; be able to remount
> +                                             ;; /etc/resolv.conf as read-only,
> +                                             ;; so we say that it is writable
> +                                             ;; here, even though in practice
> +                                             ;; it is not.
> +                                             (writable? #t))))
>                                       %network-configuration-files)

Not sure I understand: why would bind-mounting /etc/resolv.conf
read-only fail?

Thanks,
Ludo’.

Re: [PATCH] environment: container: Do not remount network files as read-only.

[Thompson, David]

On Fri, Mar 18, 2016 at 4:51 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> "Thompson, David" <dthompson2@worcester.edu> skribis:
>
>> I noticed that 'guix environment --container --network' didn't work on
>> an Ubuntu machine I was on, and the culprit was remounting things like
>> /etc/resolv.conf read-only after the initial bind mount.
>
> [...]
>
>>                                              (file-system-mapping
>>                                               (source file)
>>                                               (target file)
>> -                                             (writable? #f))))
>> +                                             ;; An unpriviliged user might not
>> +                                             ;; be able to remount
>> +                                             ;; /etc/resolv.conf as read-only,
>> +                                             ;; so we say that it is writable
>> +                                             ;; here, even though in practice
>> +                                             ;; it is not.
>> +                                             (writable? #t))))
>>                                       %network-configuration-files)
>
> Not sure I understand: why would bind-mounting /etc/resolv.conf
> read-only fail?

I haven't figured out the exact reason yet, but here's a strace
snippet as proof:

[pid 11334] mount("/etc/resolv.conf",
"/tmp/guix-directory.Rc4nc6//etc/resolv.conf", 0x23da000,
MS_RDONLY|MS_BIND, NULL) = 0
[pid 11334] mount("/etc/resolv.conf",
"/tmp/guix-directory.Rc4nc6//etc/resolv.conf", 0x23e4080,
MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = -1 EPERM (Operation not
permitted)

Another Ubuntu user was able to reproduce this as well.  I find it
kind of silly to mount these files read-only because an unprivileged
user couldn't write to them anyway.  WDYT?

- Dave

Re: [PATCH] environment: container: Do not remount network files as read-only.

[Drew C]

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

On Sat, Mar 26, 2016 at 7:06 AM, Thompson, David <dthompson2@worcester.edu>
wrote:

> On Fri, Mar 18, 2016 at 4:51 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> > "Thompson, David" <dthompson2@worcester.edu> skribis:
> >
> >> I noticed that 'guix environment --container --network' didn't work on
> >> an Ubuntu machine I was on, and the culprit was remounting things like
> >> /etc/resolv.conf read-only after the initial bind mount.
>


One thing that I have run across is the following :

$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1

It re-writes that file every time a new network connection is made.

$ man resolvconf
[...]
DESCRIPTION
       The resolvconf package comprises a simple database for  run-time
 name‐
       server information and a simple framework for notifying applications
of
       changes in that information.  Resolvconf thus sets  itself  up  as
 the
       intermediary  between  programs  that supply nameserver information
and
       applications that use that information.
[...]

I am not at all sure if this is the cause of the issue, but I have run into
it many times before with WiFi and me trying to edit it to 8.8.8.8, so I
figure this is a decent time to bring it up.

Cheers,

Drew Crampsie



> >
> > [...]
> >
> >>                                              (file-system-mapping
> >>                                               (source file)
> >>                                               (target file)
> >> -                                             (writable? #f))))
> >> +                                             ;; An unpriviliged user
> might not
> >> +                                             ;; be able to remount
> >> +                                             ;; /etc/resolv.conf as
> read-only,
> >> +                                             ;; so we say that it is
> writable
> >> +                                             ;; here, even though in
> practice
> >> +                                             ;; it is not.
> >> +                                             (writable? #t))))
> >>                                       %network-configuration-files)
> >
> > Not sure I understand: why would bind-mounting /etc/resolv.conf
> > read-only fail?
>
> I haven't figured out the exact reason yet, but here's a strace
> snippet as proof:
>
> [pid 11334] mount("/etc/resolv.conf",
> "/tmp/guix-directory.Rc4nc6//etc/resolv.conf", 0x23da000,
> MS_RDONLY|MS_BIND, NULL) = 0
> [pid 11334] mount("/etc/resolv.conf",
> "/tmp/guix-directory.Rc4nc6//etc/resolv.conf", 0x23e4080,
> MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = -1 EPERM (Operation not
> permitted)
>
> Another Ubuntu user was able to reproduce this as well.  I find it
> kind of silly to mount these files read-only because an unprivileged
> user couldn't write to them anyway.  WDYT?
>
> - Dave
>
>

[-- Attachment #2: Type: text/html, Size: 4638 bytes --]

Re: [PATCH] environment: container: Do not remount network files as read-only.

[Thompson, David]

On Sat, Mar 26, 2016 at 12:29 PM, Drew C <me@drewc.ca> wrote:
>
> On Sat, Mar 26, 2016 at 7:06 AM, Thompson, David <dthompson2@worcester.edu>
> wrote:
>>
>> On Fri, Mar 18, 2016 at 4:51 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> > "Thompson, David" <dthompson2@worcester.edu> skribis:
>> >
>> >> I noticed that 'guix environment --container --network' didn't work on
>> >> an Ubuntu machine I was on, and the culprit was remounting things like
>> >> /etc/resolv.conf read-only after the initial bind mount.
>
>
>
> One thing that I have run across is the following :
>
> $ cat /etc/resolv.conf
> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by
> resolvconf(8)
> #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
> nameserver 127.0.1.1
>
> It re-writes that file every time a new network connection is made.
>
> $ man resolvconf
> [...]
> DESCRIPTION
>        The resolvconf package comprises a simple database for  run-time
> name‐
>        server information and a simple framework for notifying applications
> of
>        changes in that information.  Resolvconf thus sets  itself  up  as
> the
>        intermediary  between  programs  that supply nameserver information
> and
>        applications that use that information.
> [...]
>
> I am not at all sure if this is the cause of the issue, but I have run into
> it many times before with WiFi and me trying to edit it to 8.8.8.8, so I
> figure this is a decent time to bring it up.

Interesting!  Is this on Ubuntu as well?

- Dave

Re: [PATCH] environment: container: Do not remount network files as read-only.

[Drew C]

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

It is Linux Mint 17.3, which is based on Ubuntu Trusty. So, yes, as far as
I know, it should be the same on a modern Ubuntu distro.

http://manpages.ubuntu.com/manpages/lucid/man8/resolvconf.8.html

-- drewc

On Sat, Mar 26, 2016 at 9:49 AM, Thompson, David <dthompson2@worcester.edu>
wrote:

> On Sat, Mar 26, 2016 at 12:29 PM, Drew C <me@drewc.ca> wrote:
> >
> > On Sat, Mar 26, 2016 at 7:06 AM, Thompson, David <
> dthompson2@worcester.edu>
> > wrote:
> >>
> >> On Fri, Mar 18, 2016 at 4:51 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> >> > "Thompson, David" <dthompson2@worcester.edu> skribis:
> >> >
> >> >> I noticed that 'guix environment --container --network' didn't work
> on
> >> >> an Ubuntu machine I was on, and the culprit was remounting things
> like
> >> >> /etc/resolv.conf read-only after the initial bind mount.
> >
> >
> >
> > One thing that I have run across is the following :
> >
> > $ cat /etc/resolv.conf
> > # Dynamic resolv.conf(5) file for glibc resolver(3) generated by
> > resolvconf(8)
> > #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
> > nameserver 127.0.1.1
> >
> > It re-writes that file every time a new network connection is made.
> >
> > $ man resolvconf
> > [...]
> > DESCRIPTION
> >        The resolvconf package comprises a simple database for  run-time
> > name‐
> >        server information and a simple framework for notifying
> applications
> > of
> >        changes in that information.  Resolvconf thus sets  itself  up  as
> > the
> >        intermediary  between  programs  that supply nameserver
> information
> > and
> >        applications that use that information.
> > [...]
> >
> > I am not at all sure if this is the cause of the issue, but I have run
> into
> > it many times before with WiFi and me trying to edit it to 8.8.8.8, so I
> > figure this is a decent time to bring it up.
>
> Interesting!  Is this on Ubuntu as well?
>
> - Dave
>

[-- Attachment #2: Type: text/html, Size: 2916 bytes --]

Re: [PATCH] environment: container: Do not remount network files as read-only.

[Ludovic Courtès]

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

"Thompson, David" <dthompson2@worcester.edu> skribis:

> On Fri, Mar 18, 2016 at 4:51 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> "Thompson, David" <dthompson2@worcester.edu> skribis:
>>
>>> I noticed that 'guix environment --container --network' didn't work on
>>> an Ubuntu machine I was on, and the culprit was remounting things like
>>> /etc/resolv.conf read-only after the initial bind mount.
>>
>> [...]
>>
>>>                                              (file-system-mapping
>>>                                               (source file)
>>>                                               (target file)
>>> -                                             (writable? #f))))
>>> +                                             ;; An unpriviliged user might not
>>> +                                             ;; be able to remount
>>> +                                             ;; /etc/resolv.conf as read-only,
>>> +                                             ;; so we say that it is writable
>>> +                                             ;; here, even though in practice
>>> +                                             ;; it is not.
>>> +                                             (writable? #t))))
>>>                                       %network-configuration-files)
>>
>> Not sure I understand: why would bind-mounting /etc/resolv.conf
>> read-only fail?
>
> I haven't figured out the exact reason yet, but here's a strace
> snippet as proof:
>
> [pid 11334] mount("/etc/resolv.conf",
> "/tmp/guix-directory.Rc4nc6//etc/resolv.conf", 0x23da000,
> MS_RDONLY|MS_BIND, NULL) = 0
> [pid 11334] mount("/etc/resolv.conf",
> "/tmp/guix-directory.Rc4nc6//etc/resolv.conf", 0x23e4080,
> MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = -1 EPERM (Operation not
> permitted)
>
> Another Ubuntu user was able to reproduce this as well.

Looking at the resolvconf man page that Drew mentioned, it seems that
/etc/resolv.conf is a symlink when resolvconf is in used, right?

If yes, does this make a difference:


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

diff --git a/gnu/build/file-systems.scm b/gnu/build/file-systems.scm
index 58ccf59..a329eeb 100644
--- a/gnu/build/file-systems.scm
+++ b/gnu/build/file-systems.scm
@@ -378,7 +378,7 @@ corresponds to the symbols listed in FLAGS."
 
 (define (regular-file? file-name)
   "Return #t if FILE-NAME is a regular file."
-  (eq? (stat:type (stat file-name)) 'regular))
+  (memq (stat:type (stat file-name)) '(regular symlink)))
 
 (define* (mount-file-system spec #:key (root "/root"))
   "Mount the file system described by SPEC under ROOT.  SPEC must have the

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


It may be that the result after this is that you get /etc/resolv.conf in
the container, but it’s a dangling symlink.  But isn’t it the case
already with the patch you propose?

Thanks for finding all these curiosities.  :-)

Ludo’.

Re: [PATCH] environment: container: Do not remount network files as read-only.

[Drew C]

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

On Sat, Mar 26, 2016 at 11:43 AM, Ludovic Courtès <ludo@gnu.org> wrote:

> "Thompson, David" <dthompson2@worcester.edu> skribis:
>
> > On Fri, Mar 18, 2016 at 4:51 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> >> "Thompson, David" <dthompson2@worcester.edu> skribis:
> >>
> >>> I noticed that 'guix environment --container --network' didn't work on
> >>> an Ubuntu machine I was on, and the culprit was remounting things like
> >>> /etc/resolv.conf read-only after the initial bind mount.
> >>
> >> [...]
> >>
> >>>                                              (file-system-mapping
> >>>                                               (source file)
> >>>                                               (target file)
> >>> -                                             (writable? #f))))
> >>> +                                             ;; An unpriviliged user
> might not
> >>> +                                             ;; be able to remount
> >>> +                                             ;; /etc/resolv.conf as
> read-only,
> >>> +                                             ;; so we say that it is
> writable
> >>> +                                             ;; here, even though in
> practice
> >>> +                                             ;; it is not.
> >>> +                                             (writable? #t))))
> >>>                                       %network-configuration-files)
> >>
> >> Not sure I understand: why would bind-mounting /etc/resolv.conf
> >> read-only fail?
> >
> > I haven't figured out the exact reason yet, but here's a strace
> > snippet as proof:
> >
> > [pid 11334] mount("/etc/resolv.conf",
> > "/tmp/guix-directory.Rc4nc6//etc/resolv.conf", 0x23da000,
> > MS_RDONLY|MS_BIND, NULL) = 0
> > [pid 11334] mount("/etc/resolv.conf",
> > "/tmp/guix-directory.Rc4nc6//etc/resolv.conf", 0x23e4080,
> > MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = -1 EPERM (Operation not
> > permitted)
> >
> > Another Ubuntu user was able to reproduce this as well.
>
> Looking at the resolvconf man page that Drew mentioned, it seems that
> /etc/resolv.conf is a symlink when resolvconf is in used, right?
>

Correct :

$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 29 Oct  2 08:36 /etc/resolv.conf ->
../run/resolvconf/resolv.conf



>
> If yes, does this make a difference:
>
>
>
> It may be that the result after this is that you get /etc/resolv.conf in
> the container, but it’s a dangling symlink.  But isn’t it the case
> already with the patch you propose?
>
> Thanks for finding all these curiosities.  :-)
>
> Ludo’.
>
>

[-- Attachment #2: Type: text/html, Size: 4111 bytes --]

Re: [PATCH] environment: container: Do not remount network files as read-only.

[Thompson, David]

On Sat, Mar 26, 2016 at 2:43 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> "Thompson, David" <dthompson2@worcester.edu> skribis:
>
>> On Fri, Mar 18, 2016 at 4:51 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> "Thompson, David" <dthompson2@worcester.edu> skribis:
>>>
>>>> I noticed that 'guix environment --container --network' didn't work on
>>>> an Ubuntu machine I was on, and the culprit was remounting things like
>>>> /etc/resolv.conf read-only after the initial bind mount.
>>>
>>> [...]
>>>
>>>>                                              (file-system-mapping
>>>>                                               (source file)
>>>>                                               (target file)
>>>> -                                             (writable? #f))))
>>>> +                                             ;; An unpriviliged user might not
>>>> +                                             ;; be able to remount
>>>> +                                             ;; /etc/resolv.conf as read-only,
>>>> +                                             ;; so we say that it is writable
>>>> +                                             ;; here, even though in practice
>>>> +                                             ;; it is not.
>>>> +                                             (writable? #t))))
>>>>                                       %network-configuration-files)
>>>
>>> Not sure I understand: why would bind-mounting /etc/resolv.conf
>>> read-only fail?
>>
>> I haven't figured out the exact reason yet, but here's a strace
>> snippet as proof:
>>
>> [pid 11334] mount("/etc/resolv.conf",
>> "/tmp/guix-directory.Rc4nc6//etc/resolv.conf", 0x23da000,
>> MS_RDONLY|MS_BIND, NULL) = 0
>> [pid 11334] mount("/etc/resolv.conf",
>> "/tmp/guix-directory.Rc4nc6//etc/resolv.conf", 0x23e4080,
>> MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = -1 EPERM (Operation not
>> permitted)
>>
>> Another Ubuntu user was able to reproduce this as well.
>
> Looking at the resolvconf man page that Drew mentioned, it seems that
> /etc/resolv.conf is a symlink when resolvconf is in used, right?
>
> If yes, does this make a difference:

/etc/resolv.conf is a symlink, but the patch doesn't work.

> It may be that the result after this is that you get /etc/resolv.conf in
> the container, but it’s a dangling symlink.  But isn’t it the case
> already with the patch you propose?

No,  /etc/resolv.conf appears as a regular file inside the container,
even though it's a symlink outside.  The mount namespace does the
right thing and I can read the contents of it from within the
container.  No dangling symlink! :D

I tried using --expose with a symlink as an attempt to replicate the
problem with another file, but things went fine!  I'm confused.
What's the correct patch here now? :)

- Dave

Re: [PATCH] environment: container: Do not remount network files as read-only.

[Ludovic Courtès]

"Thompson, David" <dthompson2@worcester.edu> skribis:

> On Sat, Mar 26, 2016 at 2:43 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> "Thompson, David" <dthompson2@worcester.edu> skribis:
>>
>>> On Fri, Mar 18, 2016 at 4:51 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>>> "Thompson, David" <dthompson2@worcester.edu> skribis:
>>>>
>>>>> I noticed that 'guix environment --container --network' didn't work on
>>>>> an Ubuntu machine I was on, and the culprit was remounting things like
>>>>> /etc/resolv.conf read-only after the initial bind mount.
>>>>
>>>> [...]
>>>>
>>>>>                                              (file-system-mapping
>>>>>                                               (source file)
>>>>>                                               (target file)
>>>>> -                                             (writable? #f))))
>>>>> +                                             ;; An unpriviliged user might not
>>>>> +                                             ;; be able to remount
>>>>> +                                             ;; /etc/resolv.conf as read-only,
>>>>> +                                             ;; so we say that it is writable
>>>>> +                                             ;; here, even though in practice
>>>>> +                                             ;; it is not.
>>>>> +                                             (writable? #t))))
>>>>>                                       %network-configuration-files)
>>>>
>>>> Not sure I understand: why would bind-mounting /etc/resolv.conf
>>>> read-only fail?
>>>
>>> I haven't figured out the exact reason yet, but here's a strace
>>> snippet as proof:
>>>
>>> [pid 11334] mount("/etc/resolv.conf",
>>> "/tmp/guix-directory.Rc4nc6//etc/resolv.conf", 0x23da000,
>>> MS_RDONLY|MS_BIND, NULL) = 0
>>> [pid 11334] mount("/etc/resolv.conf",
>>> "/tmp/guix-directory.Rc4nc6//etc/resolv.conf", 0x23e4080,
>>> MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = -1 EPERM (Operation not
>>> permitted)
>>>
>>> Another Ubuntu user was able to reproduce this as well.
>>
>> Looking at the resolvconf man page that Drew mentioned, it seems that
>> /etc/resolv.conf is a symlink when resolvconf is in used, right?
>>
>> If yes, does this make a difference:
>
> /etc/resolv.conf is a symlink, but the patch doesn't work.
>
>> It may be that the result after this is that you get /etc/resolv.conf in
>> the container, but it’s a dangling symlink.  But isn’t it the case
>> already with the patch you propose?
>
> No,  /etc/resolv.conf appears as a regular file inside the container,
> even though it's a symlink outside.  The mount namespace does the
> right thing and I can read the contents of it from within the
> container.  No dangling symlink! :D
>
> I tried using --expose with a symlink as an attempt to replicate the
> problem with another file, but things went fine!  I'm confused.
> What's the correct patch here now? :)

I cannot reproduce the problem with this minimum test case (the two
‘mount’ call succeed):

--8<---------------cut here---------------start------------->8---
(use-modules (guix build syscalls)
             (gnu build linux-container))

(chdir "/tmp")
(false-if-exception (delete-file "foo"))
(false-if-exception (umount "bar"))
(false-if-exception (delete-file "bar"))

(symlink "/etc/resolv.conf" "foo")
(close-port (open-output-file "bar"))
(mount "/tmp/foo" "/tmp/bar" "none" (logior MS_BIND MS_RDONLY))
(mount "/tmp/foo" "/tmp/bar" "none" (logior MS_BIND MS_RDONLY MS_REMOUNT))
--8<---------------cut here---------------end--------------->8---

Maybe we should try to throw in ‘call-with-container’ somewhere in there
to be closer to the actual problem, dunno.

It’s a bit frustrating that we don’t understand the situation.  If you
wish, I think it’s fine to commit this patch, but please make sure to
mention that the problem occurs when /etc/resolv.conf is a symlink, and
add a link to this discussion.

(FWIW I’m planning to push have the release ready on Monday night.)

Thanks!

Ludo’.

Re: [PATCH] environment: container: Do not remount network files as read-only.

[Thompson, David]

On Sun, Mar 27, 2016 at 1:43 PM, Ludovic Courtès <ludo@gnu.org> wrote:

> I cannot reproduce the problem with this minimum test case (the two
> ‘mount’ call succeed):
>
> --8<---------------cut here---------------start------------->8---
> (use-modules (guix build syscalls)
>              (gnu build linux-container))
>
> (chdir "/tmp")
> (false-if-exception (delete-file "foo"))
> (false-if-exception (umount "bar"))
> (false-if-exception (delete-file "bar"))
>
> (symlink "/etc/resolv.conf" "foo")
> (close-port (open-output-file "bar"))
> (mount "/tmp/foo" "/tmp/bar" "none" (logior MS_BIND MS_RDONLY))
> (mount "/tmp/foo" "/tmp/bar" "none" (logior MS_BIND MS_RDONLY MS_REMOUNT))
> --8<---------------cut here---------------end--------------->8---
>
> Maybe we should try to throw in ‘call-with-container’ somewhere in there
> to be closer to the actual problem, dunno.
>
> It’s a bit frustrating that we don’t understand the situation.  If you
> wish, I think it’s fine to commit this patch, but please make sure to
> mention that the problem occurs when /etc/resolv.conf is a symlink, and
> add a link to this discussion.

I found the culprit!  This problem occurs with *any* file remounted
read-only from a tmpfs.  In Ubuntu, /etc/resolv.conf is a symlink to
/run/resolvconf/resolv.conf, and /run is a tmpfs.  I did this to
confirm the issue with another file on GuixSD:

echo foobar > /run/user/foo
guix environment --container --expose=/run/user/foo --ad-hoc coreutils

Where /run/user is a tmpfs.  It should fail with an exit status of 1.
I don't know why tmpfs is an issue, nor do I know how work around it.
I've been searching around for answers but haven't found any leads
yet.  Any thoughts?

> (FWIW I’m planning to push have the release ready on Monday night.)

Maybe we'll have to punt on this for the release, but I really hope it
can be fixed in time!  This is the last thing I need to make networked
containers "just work" on Ubuntu-based distros.

- Dave