[lkml]   [2005]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[patch 0/13] NFSACL protocol extension for NFSv3
    This patchset implements the NFSACL protocol extension, which consists
    of the GETACL and SETACL RPCs. I would appreciate to have these patches
    in -mm to give them more exposure. (This has nothing to do with NFSv4
    acls, by the way.)

    The actual access decisions are performed using the ACCESS RPC which is
    part of NFSv3 proper, and is independent of acls. The GETACL and SETACL
    RPCs are mainly used by tools like getfacl and setfacl, and ls (which
    merely displays whether or not a file's permissions go beyond the file
    mode permission bits). In addition, for files created inside directories
    that have a default acl, SETACL is used at file create time to implement
    the POSIX ACL file create semantics (see the comment in
    nfsacl-umask.diff for a detailed explanation).

    We have been shipping a slightly older version of this patch in SuSE
    Linux 8.2, 9.0, 9.1, and SLES9. Until recently acls were not cached on
    the client side; we didn't see this as a huge performance issue.
    Nevertheless, this version now also caches acls on the client.

    The protocol is compatible with the Solaris version. Solaris has
    slightly different acl semantics; they are based on an earlier
    POSIX acl draft than the Linux version. Other than Linux, Solaris does
    not allow three-entry acls (user::, group::, other::). Where Linux has
    three-entry acls, Solaris makes up a fourth mask:: entry with the same
    permissions as the group:: entry. The NFSACL protocol follows the
    Solaris semantics, so we also fake a fourth entry for three-entry
    acls, and give it the group:: entry permissions. When receiving a
    four-entry acl, we cannot tell three-entry from four-entry acls if the
    group:: entry permissions equal the mask:: entry permissions. (If they
    differ, we know we have a "real" four-entry acl). This incompatibility
    causes mask entries to be lost in very rare cases.

    Four-entry acls are extremely rare and not very useful; I never stumbled
    upon them in real life. Judging from that and from the experience of
    shipping with this incompatibility for almost two years now, I guess we
    can safely continue to ignore this issue. It's not fixable within NFSACL
    without breaking Solaris, anyway.

    Andreas Gruenbacher <>

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:09    [W:0.019 / U:32.912 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site