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

["Thompson, David" <dthompson2@worcester.edu>]

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