1. 08 12月, 2010 1 次提交
    • J
      Smack: Transmute labels on specified directories · 5c6d1125
      Jarkko Sakkinen 提交于
      In a situation where Smack access rules allow processes
      with multiple labels to write to a directory it is easy
      to get into a situation where the directory gets cluttered
      with files that the owner can't deal with because while
      they could be written to the directory a process at the
      label of the directory can't write them. This is generally
      the desired behavior, but when it isn't it is a real
      issue.
      
      This patch introduces a new attribute SMACK64TRANSMUTE that
      instructs Smack to create the file with the label of the directory
      under certain circumstances.
      
      A new access mode, "t" for transmute, is made available to
      Smack access rules, which are expanded from "rwxa" to "rwxat".
      If a file is created in a directory marked as transmutable
      and if access was granted to perform the operation by a rule
      that included the transmute mode, then the file gets the
      Smack label of the directory instead of the Smack label of the
      creating process.
      
      Note that this is equivalent to creating an empty file at the
      label of the directory and then having the other process write
      to it. The transmute scheme requires that both the access rule
      allows transmutation and that the directory be explicitly marked.
      Signed-off-by: NJarkko Sakkinen <ext-jarkko.2.sakkinen@nokia.com>
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      5c6d1125
  2. 02 12月, 2010 1 次提交
    • C
      This patch adds a new security attribute to Smack called · 676dac4b
      Casey Schaufler 提交于
      SMACK64EXEC. It defines label that is used while task is
      running.
      
      Exception: in smack_task_wait() child task is checked
      for write access to parent task using label inherited
      from the task that forked it.
      
      Fixed issues from previous submit:
      - SMACK64EXEC was not read when SMACK64 was not set.
      - inode security blob was not updated after setting
        SMACK64EXEC
      - inode security blob was not updated when removing
        SMACK64EXEC
      676dac4b
  3. 02 8月, 2010 1 次提交
  4. 22 5月, 2010 1 次提交
  5. 17 12月, 2009 1 次提交
    • C
      sanitize xattr handler prototypes · 431547b3
      Christoph Hellwig 提交于
      Add a flags argument to struct xattr_handler and pass it to all xattr
      handler methods.  This allows using the same methods for multiple
      handlers, e.g. for the ACL methods which perform exactly the same action
      for the access and default ACLs, just using a different underlying
      attribute.  With a little more groundwork it'll also allow sharing the
      methods for the regular user/trusted/secure handlers in extN, ocfs2 and
      jffs2 like it's already done for xfs in this patch.
      
      Also change the inode argument to the handlers to a dentry to allow
      using the handlers mechnism for filesystems that require it later,
      e.g. cifs.
      
      [with GFS2 bits updated by Steven Whitehouse <swhiteho@redhat.com>]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NJames Morris <jmorris@namei.org>
      Acked-by: NJoel Becker <joel.becker@oracle.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      431547b3
  6. 10 9月, 2009 1 次提交
  7. 29 4月, 2008 1 次提交
  8. 06 2月, 2008 1 次提交
  9. 12 2月, 2007 1 次提交
  10. 10 10月, 2006 1 次提交
    • B
      [PATCH] Introduce vfs_listxattr · 659564c8
      Bill Nottingham 提交于
      This patch moves code out of fs/xattr.c:listxattr into a new function -
      vfs_listxattr. The code for vfs_listxattr was originally submitted by Bill
      Nottingham <notting@redhat.com> to Unionfs.
      
      Sorry about that.  The reason for this submission is to make the
      listxattr code in fs/xattr.c a little cleaner (as well as to clean up
      some code in Unionfs.)
      
      Currently, Unionfs has vfs_listxattr defined in its code.  I think
      that's very ugly, and I'd like to see it (re)moved.  The logical place
      to put it, is along side of all the other vfs_*xattr functions.
      
      Overall, I think this patch is benefitial for both kernel.org kernel and
      Unionfs.
      Signed-off-by: NJosef "Jeff" Sipek <jsipek@cs.sunysb.edu>
      Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      659564c8
  11. 11 1月, 2006 2 次提交
  12. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4