1. 24 6月, 2009 1 次提交
  2. 01 4月, 2009 1 次提交
  3. 20 3月, 2009 1 次提交
  4. 27 7月, 2008 1 次提交
    • A
      [PATCH] sanitize ->permission() prototype · e6305c43
      Al Viro 提交于
      * kill nameidata * argument; map the 3 bits in ->flags anybody cares
        about to new MAY_... ones and pass with the mask.
      * kill redundant gfs2_iop_permission()
      * sanitize ecryptfs_permission()
      * fix remaining places where ->permission() instances might barf on new
        MAY_... found in mask.
      
      The obvious next target in that direction is permission(9)
      
      folded fix for nfs_permission() breakage from Miklos Szeredi <mszeredi@suse.cz>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      e6305c43
  5. 08 1月, 2008 1 次提交
  6. 06 11月, 2007 1 次提交
  7. 27 10月, 2007 1 次提交
  8. 20 10月, 2007 1 次提交
    • K
      [JFFS2] Tidy up fix for ACL/permissions problem. · cfc8dc6f
      KaiGai Kohei 提交于
      [In commit 9ed437c5 we fixed a problem 
      with standard permissions on newly-created inodes, when POSIX ACLs are 
      enabled. This cleans it up...]
      
      The attached patch separate jffs2_init_acl() into two parts.
      
      The one is jffs2_init_acl_pre() called from jffs2_new_inode().
      It compute ACL oriented inode->i_mode bits, and allocate in-memory ACL
      objects associated with the new inode just before when inode meta
      infomation is written to the medium.
      
      The other is jffs2_init_acl_post() called from jffs2_symlink(),
      jffs2_mkdir(), jffs2_mknod() and jffs2_do_create().
      It actually writes in-memory ACL objects into the medium next to
      the success of writing meta-information.
      
      In the current implementation, we have to write a same inode meta
      infomation twice when inode->i_mode is updated by the default ACL.
      However, we can avoid the behavior by putting an updated i_mode
      before it is written at first, as jffs2_init_acl_pre() doing.
      Signed-off-by: NKaiGai Kohei <kaigai@ak.jp.nec.com>
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      cfc8dc6f
  9. 22 8月, 2007 1 次提交
  10. 18 7月, 2007 1 次提交
    • S
      Introduce is_owner_or_cap() to wrap CAP_FOWNER use with fsuid check · 3bd858ab
      Satyam Sharma 提交于
      Introduce is_owner_or_cap() macro in fs.h, and convert over relevant
      users to it. This is done because we want to avoid bugs in the future
      where we check for only effective fsuid of the current task against a
      file's owning uid, without simultaneously checking for CAP_FOWNER as
      well, thus violating its semantics.
      [ XFS uses special macros and structures, and in general looked ...
      untouchable, so we leave it alone -- but it has been looked over. ]
      
      The (current->fsuid != inode->i_uid) check in generic_permission() and
      exec_permission_lite() is left alone, because those operations are
      covered by CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH. Similarly operations
      falling under the purview of CAP_CHOWN and CAP_LEASE are also left alone.
      Signed-off-by: NSatyam Sharma <ssatyam@cse.iitk.ac.in>
      Cc: Al Viro <viro@ftp.linux.org.uk>
      Acked-by: NSerge E. Hallyn <serge@hallyn.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3bd858ab
  11. 25 4月, 2007 1 次提交
    • D
      [JFFS2] Tidy up licensing/copyright boilerplate. · c00c310e
      David Woodhouse 提交于
      In particular, remove the bit in the LICENCE file about contacting
      Red Hat for alternative arrangements. Their errant IS department broke
      that arrangement a long time ago -- the policy of collecting copyright
      assignments from contributors came to an end when the plug was pulled on
      the servers hosting the project, without notice or reason.
      
      We do still dual-license it for use with eCos, with the GPL+exception
      licence approved by the FSF as being GPL-compatible. It's just that nobody
      has the right to license it differently.
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      c00c310e
  12. 04 12月, 2006 1 次提交
  13. 02 7月, 2006 1 次提交
  14. 27 6月, 2006 1 次提交
  15. 13 5月, 2006 4 次提交