lkml.org 
[lkml]   [2018]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: BUG: Mount ignores mount options
    On Fri, Aug 10, 2018 at 9:14 AM, Theodore Y. Ts'o <tytso@mit.edu> wrote:
    > And I'm not really sure it helps the container use
    > case, since the whole point is they want their "guest" to be able to
    > blithely run "mount /dev/sda1 -o noxattr /mnt" and not worry about the
    > fact that in some other container, someone had run "mount /dev/sda1 -o
    > xattr /mnt". But having the second mount fail because of conflicting
    > mount option breaks the illusion that containers are functionally as
    > rich as VM's.

    If the same block device is visible, with rw access, in two different
    containers, I don't see any anything good can happen. Sure, with the
    current somewhat erratic semantics of mount(2), something kind of sort
    of reasonable happens if they both mount it. But if one or both of
    them try to use, say, tune2fs or fsck, it's not going to go well. And
    a situation where they mount with different options and the result
    depends on the order of the mounts is just plain bad.

    I see four sane ways to deal with this:

    1. Don't put the block device in the container at all. The container
    manager mounts it.

    2. Use seccomp or a similar mechanism to intercept and emulate the
    mount request.

    3. Teach the filesystem driver to do something sensible. This will
    inherently be per-fs, and probably involves some serious magic or
    allowing filesystem-specific vfsmount options.

    4. Introduce a concept of a special kind of fake block device that
    refers to an existing superblock, doesn't allow direct read or write,
    and does the right thing when mounted. Not obviously worth the
    effort.

    It seems to me that the current approach mostly involves crossing our fingers.

    \
     
     \ /
      Last update: 2018-08-10 22:08    [W:3.599 / U:0.616 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site