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