• Miklos Szeredi's avatar
    [PATCH] FUSE - core · d8a5ba45
    Miklos Szeredi authored
    This patch adds FUSE core.
    
    This contains the following files:
    
     o inode.c
        - superblock operations (alloc_inode, destroy_inode, read_inode,
          clear_inode, put_super, show_options)
        - registers FUSE filesystem
    
     o fuse_i.h
        - private header file
    
    Requirements
    ============
    
     The most important difference between orinary filesystems and FUSE is
     the fact, that the filesystem data/metadata is provided by a userspace
     process run with the privileges of the mount "owner" instead of the
     kernel, or some remote entity usually running with elevated
     privileges.
    
     The security implication of this is that a non-privileged user must
     not be able to use this capability to compromise the system.  Obvious
     requirements arising from this are:
    
      - mount owner should not be able to get elevated privileges with the
        help of the mounted filesystem
    
      - mount owner should not be able to induce undesired behavior in
        other users' or the super user's processes
    
      - mount owner should not get illegitimate access to information from
        other users' and the super user's processes
    
     These are currently ensured with the following constraints:
    
      1) mount is only allowed to directory or file which the mount owner
        can modify without limitation (write access + no sticky bit for
        directories)
    
      2) nosuid,nodev mount options are forced
    
      3) any process running with fsuid different from the owner is denied
         all access to the filesystem
    
     1) and 2) are ensured by the "fusermount" mount utility which is a
        setuid root application doing the actual mount operation.
    
     3) is ensured by a check in the permission() method in kernel
    
     I started thinking about doing 3) in a different way because Christoph
     H. made a big deal out of it, saying that FUSE is unacceptable into
     mainline in this form.
    
     The suggested use of private namespaces would be OK, but in their
     current form have many limitations that make their use impractical (as
     discussed in this thread).
    
     Suggested improvements that would address these limitations:
    
       - implement shared subtrees
    
       - allow a process to join an existing namespace (make namespaces
         first-class objects)
    
       - implement the namespace creation/joining in a PAM module
    
     With all that in place the check of owner against current->fsuid may
     be removed from the FUSE kernel module, without compromising the
     security requirements.
    
     Suid programs still interesting questions, since they get access even
     to the private namespace causing some information leak (exact
     order/timing of filesystem operations performed), giving some
     ptrace-like capabilities to unprivileged users.  BTW this problem is
     not strictly limited to the namespace approach, since suid programs
     setting fsuid and accessing users' files will succeed with the current
     approach too.
    Signed-off-by: default avatarMiklos Szeredi <miklos@szeredi.hu>
    Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    d8a5ba45
Makefile 95 Bytes