Bug 690545 - lxc fails to create a container when a ".oldrootfs" submount is already unmounted
Summary: lxc fails to create a container when a ".oldrootfs" submount is already unmou...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Jiri Denemark
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-24 15:58 UTC by Brice Arnould
Modified: 2016-04-26 13:29 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-23 12:23:42 UTC


Attachments (Terms of Use)
Suggested fix (1.36 KB, patch)
2011-03-24 15:59 UTC, Brice Arnould
no flags Details | Diff
Suggested fix v2 (1.30 KB, patch)
2011-03-28 14:21 UTC, Brice Arnould
no flags Details | Diff

Description Brice Arnould 2011-03-24 15:58:00 UTC
Description of problem:
 On a system where I use libvirt's LXC and autofs, lxcContainerUnmountOldFS fails, possibly because it tries unmounting filesystems that were already unmounted by autofs while it was working.
I believe that it is possible for a malevolent user to trigger this problem with careful accesses to /net or to removable devices, making this a local DoS attack.

Factual information :
 - version number of the libvirt build: 0.8.8
 - hardware architecture being used : amd64
 - stracing the process gives the following output :
[pid  9763] write(2, "16:08:45.287: 1: debug : lxcContainerUnmountOldFS:596 : Umount /.oldroot/mnt/gasiho/10.5.5.54/VFS/00/home-0\n", 108) = 108
[pid  9763] umount("/.oldroot/mnt/gasiho/10.5.5.54/VFS/00/home-0", 0) = 0
[pid  9763] write(2, "16:08:45.287: 1: debug : lxcContainerUnmountOldFS:596 : Umount /.oldroot/mnt/gasiho/10.5.5.54/VFS/00\n", 101) = 101
[pid  9763] umount("/.oldroot/mnt/gasiho/10.5.5.54/VFS/00", 0) = 0
[pid  9763] write(2, "16:08:45.287: 1: debug : lxcContainerUnmountOldFS:596 : Umount /.oldroot/mnt/gasiho/10.5.5.54/VFS/00\n", 101) = 101
[pid  9763] umount("/.oldroot/mnt/gasiho/10.5.5.54/VFS/00", 0) = -1 ENOENT (No such file or directory)
[pid  9763] write(2, "16:08:45.287: 1: error : lxcContainerUnmountOldFS:600 : Failed to unmount '/.oldroot/mnt/gasiho/10.5.5.54/VFS/00': No such file or directory\n", 141) = 141

(that last error cancels the creation process)

Suggested fix:
 lxcContainerUnmountOldFS should only fail if unmounting .oldroot fails, not if a single submount of .oldroot fails to unmount. The attached (untested) patch tries to implement that.

Comment 1 Brice Arnould 2011-03-24 15:59:11 UTC
Created attachment 487385 [details]
Suggested fix

Comment 2 Daniel Berrangé 2011-03-28 10:13:21 UTC
I don't think ignoring all sub-mount umount failures is safe from a security POV, because we really need to guarantee that the container OS can never access any filesystem mount from the host OS. Thus we need to fail container startup if umount fails in a way that leaves the mount visible to the guest.

I think we should thus just ignore any failure with errno == ENOENT.

Comment 3 Brice Arnould 2011-03-28 10:45:47 UTC
If unmounting .oldroot succeeds, it means that the submounts are unmounted, and even if they weren't they would be inaccessible.

Testing errno would also work, it's just slightly less nice IMHO :
 - we would need to think of all possible errors (eg. EINVAL should be accepted for the case where autofs has removed the mount but has not yet removed the directory) and maintain the list of those errors.
 - we would have problems if a signal handler were called, potentially changing errno
 - errno might not be threadsafe on non-Posix platforms
Admittedly those potential issues are *very* unlikely, but the change I suggest (only testing the unmount of ".oldroot") avoids them while still allowing to be sure that the sub-mounts are unmounted. Therefore it is slightly better in my opinion.

Comment 4 Brice Arnould 2011-03-28 14:21:06 UTC
Created attachment 488156 [details]
Suggested fix v2

"Slightly better", except it shows the wrong error message xD. Sorry for that, please find a new version attached.

Comment 5 Cole Robinson 2016-03-23 12:23:42 UTC
Sorry that second patch never received a response. I can't tell by inspecting the current code whether this was fixed or not, but things have changed quite a bit in the lxc driver in the past 5 years. Closing as DEFERRED, but if anyone can still reproduce, please reopen


Note You need to log in before you can comment on or make changes to this bug.