1. 18 10月, 2007 2 次提交
    • L
      9p: attach-per-user · ba17674f
      Latchesar Ionkov 提交于
      The 9P2000 protocol requires the authentication and permission checks to be
      done in the file server. For that reason every user that accesses the file
      server tree has to authenticate and attach to the server separately.
      Multiple users can share the same connection to the server.
      
      Currently v9fs does a single attach and executes all I/O operations as a
      single user. This makes using v9fs in multiuser environment unsafe as it
      depends on the client doing the permission checking.
      
      This patch improves the 9P2000 support by allowing every user to attach
      separately. The patch defines three modes of access (new mount option
      'access'):
      
      - attach-per-user (access=user) (default mode for 9P2000.u)
       If a user tries to access a file served by v9fs for the first time, v9fs
       sends an attach command to the server (Tattach) specifying the user. If
       the attach succeeds, the user can access the v9fs tree.
       As there is no uname->uid (string->integer) mapping yet, this mode works
       only with the 9P2000.u dialect.
      
      - allow only one user to access the tree (access=<uid>)
       Only the user with uid can access the v9fs tree. Other users that attempt
       to access it will get EPERM error.
      
      - do all operations as a single user (access=any) (default for 9P2000)
       V9fs does a single attach and all operations are done as a single user.
       If this mode is selected, the v9fs behavior is identical with the current
       one.
      Signed-off-by: NLatchesar Ionkov <lucho@ionkov.net>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      ba17674f
    • E
      9p: Make transports dynamic · a80d923e
      Eric Van Hensbergen 提交于
      This patch abstracts out the interfaces to underlying transports so that
      new transports can be added as modules.  This should also allow kernel
      configuration of transports without ifdef-hell.
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      a80d923e
  2. 17 10月, 2007 5 次提交
    • D
      r/o bind mounts: filesystem helpers for custom 'struct file's · ce8d2cdf
      Dave Hansen 提交于
      Why do we need r/o bind mounts?
      
      This feature allows a read-only view into a read-write filesystem.  In the
      process of doing that, it also provides infrastructure for keeping track of
      the number of writers to any given mount.
      
      This has a number of uses.  It allows chroots to have parts of filesystems
      writable.  It will be useful for containers in the future because users may
      have root inside a container, but should not be allowed to write to
      somefilesystems.  This also replaces patches that vserver has had out of the
      tree for several years.
      
      It allows security enhancement by making sure that parts of your filesystem
      read-only (such as when you don't trust your FTP server), when you don't want
      to have entire new filesystems mounted, or when you want atime selectively
      updated.  I've been using the following script to test that the feature is
      working as desired.  It takes a directory and makes a regular bind and a r/o
      bind mount of it.  It then performs some normal filesystem operations on the
      three directories, including ones that are expected to fail, like creating a
      file on the r/o mount.
      
      This patch:
      
      Some filesystems forego the vfs and may_open() and create their own 'struct
      file's.
      
      This patch creates a couple of helper functions which can be used by these
      filesystems, and will provide a unified place which the r/o bind mount code
      may patch.
      
      Also, rename an existing, static-scope init_file() to a less generic name.
      Signed-off-by: NDave Hansen <haveblue@us.ibm.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ce8d2cdf
    • D
      KEYS: Make request_key() and co fundamentally asynchronous · 76181c13
      David Howells 提交于
      Make request_key() and co fundamentally asynchronous to make it easier for
      NFS to make use of them.  There are now accessor functions that do
      asynchronous constructions, a wait function to wait for construction to
      complete, and a completion function for the key type to indicate completion
      of construction.
      
      Note that the construction queue is now gone.  Instead, keys under
      construction are linked in to the appropriate keyring in advance, and that
      anyone encountering one must wait for it to be complete before they can use
      it.  This is done automatically for userspace.
      
      The following auxiliary changes are also made:
      
       (1) Key type implementation stuff is split from linux/key.h into
           linux/key-type.h.
      
       (2) AF_RXRPC provides a way to allocate null rxrpc-type keys so that AFS does
           not need to call key_instantiate_and_link() directly.
      
       (3) Adjust the debugging macros so that they're -Wformat checked even if
           they are disabled, and make it so they can be enabled simply by defining
           __KDEBUG to be consistent with other code of mine.
      
       (3) Documentation.
      
      [alan@lxorguk.ukuu.org.uk: keys: missing word in documentation]
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      76181c13
    • R
      Remove "unsafe" from module struct · af49d924
      Rusty Russell 提交于
      Adrian Bunk points out that "unsafe" was used to mark modules touched by
      the deprecated MOD_INC_USE_COUNT interface, which has long gone.  It's time
      to remove the member from the module structure, as well.
      
      If you want a module which can't unload, don't register an exit function.
      
      (Vlad Yasevich says SCTP is now safe to unload, so just remove the
      __unsafe there).
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Acked-by: NShannon Nelson <shannon.nelson@intel.com>
      Acked-by: NDan Williams <dan.j.williams@intel.com>
      Acked-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Cc: Sridhar Samudrala <sri@us.ibm.com>
      Cc: Adrian Bunk <bunk@stusta.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      af49d924
    • C
      Slab API: remove useless ctor parameter and reorder parameters · 4ba9b9d0
      Christoph Lameter 提交于
      Slab constructors currently have a flags parameter that is never used.  And
      the order of the arguments is opposite to other slab functions.  The object
      pointer is placed before the kmem_cache pointer.
      
      Convert
      
              ctor(void *object, struct kmem_cache *s, unsigned long flags)
      
      to
      
              ctor(struct kmem_cache *s, void *object)
      
      throughout the kernel
      
      [akpm@linux-foundation.org: coupla fixes]
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4ba9b9d0
    • A
      net/sunrpc/xprtrdma/verbs.c printk warning fix · a56daeb7
      Andrew Morton 提交于
      sparc64:
      
      net/sunrpc/xprtrdma/verbs.c:1264: warning: long long unsigned int format, u64 arg (arg 3)
      net/sunrpc/xprtrdma/verbs.c:1264: warning: long long unsigned int format, u64 arg (arg 4)
      
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a56daeb7
  3. 16 10月, 2007 33 次提交