guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ludovic Courtès
Subject: Re: [PATCH] environment: container: Do not remount network files as read-only.
Date: Sun, 27 Mar 2016 19:43:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

"Thompson, David" <address@hidden> skribis:

> On Sat, Mar 26, 2016 at 2:43 PM, Ludovic Courtès <address@hidden> wrote:
>> "Thompson, David" <address@hidden> skribis:
>>
>>> On Fri, Mar 18, 2016 at 4:51 PM, Ludovic Courtès <address@hidden> wrote:
>>>> "Thompson, David" <address@hidden> 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’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]