• J
    orangefs: fix namespace handling · 78fee0b6
    Jann Horn 提交于
    In orangefs_inode_getxattr(), an fsuid is written to dmesg. The kuid is
    converted to a userspace uid via from_kuid(current_user_ns(), [...]), but
    since dmesg is global, init_user_ns should be used here instead.
    
    In copy_attributes_from_inode(), op_alloc() and fill_default_sys_attrs(),
    upcall structures are populated with uids/gids that have been mapped into
    the caller's namespace. However, those upcall structures are read by
    another process (the userspace filesystem driver), and that process might
    be running in another namespace. This effectively lets any user spoof its
    uid and gid as seen by the userspace filesystem driver.
    
    To fix the second issue, I just construct the opcall structures with
    init_user_ns uids/gids and require the filesystem server to run in the
    init namespace. Since orangefs is full of global state anyway (as the error
    message in DUMP_DEVICE_ERROR explains, there can only be one userspace
    orangefs filesystem driver at once), that shouldn't be a problem.
    
    [
    Why does orangefs even exist in the kernel if everything does upcalls into
    userspace? What does orangefs do that couldn't be done with the FUSE
    interface? If there is no good answer to those questions, I'd prefer to see
    orangefs kicked out of the kernel. Can that be done for something that
    shipped in a release?
    
    According to commit f7ab093f ("Orangefs: kernel client part 1"), they
    even already have a FUSE daemon, and the only rational reason (apart from
    "but most of our users report preferring to use our kernel module instead")
    given for not wanting to use FUSE is one "in-the-works" feature that could
    probably be integated into FUSE instead.
    ]
    
    This patch has been compile-tested.
    Signed-off-by: NJann Horn <jannh@google.com>
    Signed-off-by: NMike Marshall <hubcap@omnibond.com>
    78fee0b6
orangefs-cache.c 4.2 KB