1. 16 12月, 2009 1 次提交
  2. 15 12月, 2009 1 次提交
  3. 28 10月, 2009 1 次提交
    • F
      nfsd: Fix sort_pacl in fs/nfsd/nf4acl.c to actually sort groups · aba24d71
      Frank Filz 提交于
      We have been doing some extensive testing of Linux support for ACLs on
      NFDS v4. We have noticed that the server rejects ACLs where the groups
      are out of order, for example, the following ACL is rejected:
      
      A::OWNER@:rwaxtTcCy
      A::user101@domain:rwaxtcy
      A::GROUP@:rwaxtcy
      A:g:group102@domain:rwaxtcy
      A:g:group101@domain:rwaxtcy
      A::EVERYONE@:rwaxtcy
      
      Examining the server code, I found that after converting an NFS v4 ACL
      to POSIX, sort_pacl is called to sort the user ACEs and group ACEs.
      Unfortunately, a minor bug causes the group sort to be skipped.
      Signed-off-by: NFrank Filz <ffilzlnx@us.ibm.com>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      aba24d71
  4. 28 8月, 2009 1 次提交
    • F
      nfsd4: remove ACE4_IDENTIFIER_GROUP flag from GROUP@ entry · d8d0b85b
      Frank Filz 提交于
      RFC 3530 says "ACE4_IDENTIFIER_GROUP flag MUST be ignored on entries
      with these special identifiers.  When encoding entries with these
      special identifiers, the ACE4_IDENTIFIER_GROUP flag SHOULD be set to
      zero."  It really shouldn't matter either way, but the point is that
      this flag is used to distinguish named users from named groups (since
      unix allows a group to have the same name as a user), so it doesn't
      really make sense to use it on a special identifier such as this.)
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      d8d0b85b
  5. 25 8月, 2009 1 次提交
  6. 02 9月, 2008 1 次提交
  7. 18 7月, 2007 2 次提交
  8. 10 5月, 2007 1 次提交
  9. 28 3月, 2007 1 次提交
  10. 17 2月, 2007 6 次提交
  11. 04 10月, 2006 4 次提交
  12. 11 4月, 2006 2 次提交
  13. 24 3月, 2006 1 次提交
  14. 24 6月, 2005 1 次提交
  15. 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