18 Sep, 2012

1 commit

  • - In setxattr if we are setting a posix acl convert uids and gids from
    the current user namespace into the initial user namespace, before
    the xattrs are passed to the underlying filesystem.

    Untranslatable uids and gids are represented as -1 which
    posix_acl_from_xattr will represent as INVALID_UID or INVALID_GID.
    posix_acl_valid will fail if an acl from userspace has any
    INVALID_UID or INVALID_GID values. In net this guarantees that
    untranslatable posix acls will not be stored by filesystems.

    - In getxattr if we are reading a posix acl convert uids and gids from
    the initial user namespace into the current user namespace.

    Uids and gids that can not be tranlsated into the current user namespace
    will be represented as -1.

    - Replace e_id in struct posix_acl_entry with an anymouns union of
    e_uid and e_gid. For the short term retain the e_id field
    until all of the users are converted.

    - Don't set struct posix_acl.e_id in the cases where the acl type
    does not use e_id. Greatly reducing the use of ACL_UNDEFINED_ID.

    - Rework the ordering checks in posix_acl_valid so that I use kuid_t
    and kgid_t types throughout the code, and so that I don't need
    arithmetic on uid and gid types.

    Cc: Theodore Tso
    Cc: Andrew Morton
    Cc: Andreas Dilger
    Cc: Jan Kara
    Cc: Al Viro
    Signed-off-by: Eric W. Biederman

    Eric W. Biederman
     

05 Mar, 2012

1 commit

  • If a header file is making use of BUG, BUG_ON, BUILD_BUG_ON, or any
    other BUG variant in a static inline (i.e. not in a #define) then
    that header really should be including and not just
    expecting it to be implicitly present.

    We can make this change risk-free, since if the files using these
    headers didn't have exposure to linux/bug.h already, they would have
    been causing compile failures/warnings.

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

03 Aug, 2011

2 commits


01 Aug, 2011

4 commits


26 Jul, 2011

3 commits


26 Jan, 2011

1 commit

  • nfsacl_encode() allocates memory in certain cases. This of course
    is not guaranteed to work.

    Since commit 9f06c719 "SUNRPC: New xdr_streams XDR encoder API", the
    kernel's XDR encoders can't return a result indicating possibly a
    failure, so a memory allocation failure in nfsacl_encode() has become
    fatal (ie, the XDR code Oopses) in some cases.

    However, the allocated memory is a tiny fixed amount, on the order
    of 40-50 bytes. We can easily use a stack-allocated buffer for
    this, with only a wee bit of nose-holding.

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     

07 Jan, 2011

1 commit

  • This simple implementation just checks for no ACLs on the inode, and
    if so, then the rcu-walk may proceed, otherwise fail it.

    This could easily be extended to put acls under RCU and check them
    under seqlock, if need be. But this implementation is enough to show
    the rcu-walk aware permissions code for path lookups is working, and
    will handle cases where there are no ACLs or ACLs in just the final
    element.

    This patch implicity converts tmpfs to rcu-aware permission check.
    Subsequent patches onvert ext*, xfs, and, btrfs. Each of these uses
    acl/permission code in a different way, so convert them all to provide
    templates and proof of concept.

    Signed-off-by: Nick Piggin

    Nick Piggin
     

03 Dec, 2009

1 commit


25 Jun, 2009

2 commits


24 Jun, 2009

1 commit


09 Oct, 2005

1 commit

  • - added typedef unsigned int __nocast gfp_t;

    - replaced __nocast uses for gfp flags with gfp_t - it gives exactly
    the same warnings as far as sparse is concerned, doesn't change
    generated code (from gcc point of view we replaced unsigned int with
    typedef) and documents what's going on far better.

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds