Server-side NFSv4 ACL support

[Prasad P]

Requirements and Design Considerations for Server-side NFSv4 ACL support

I. Overview

    Access Control Lists (ACLs) are used to specify fine-grained access 
rights
    to file system objects.  An ACL is a list of Access Control Entries 
(ACEs),
    each specifying an entity (such as a user or a group) and some level 
of
    access for that entity.

    There are two ACL models commonly used in the current implementations,
    ACLs based on withdrawn POSIX 1003.1e draft (will refer as "POSIX 
ACLs")
    and ACLs based on NFSv4 Protocol (RFC 3530) (will refer as "NFSv4 
ACLs").

    The POSIX ACLs are implemented in many file systems.  These ACLs do 
not
    provide fine-grained access rights like NFSv4 ACLs.

    The NFSv4 ACLs are implemented on few file systems (such as GPFS).
    These ACLs resemble that of Windows NT's

    All versions of NFS (server and client) support POSIX ACLs.  But, only
    NFSv4 client supports NFSv4 ACLs.

II. Functional Requirements

    NFSv4 ACLs need to be supported by NFSv4 server.  The server needs to
    support set and get NFSv4 ACL requests from NFS clients.  It should
    provide the access based on the NFSv4 access rights of the file system
    objects.

III. Design Considerations

    Here are the possible implementation approaches to support server-side
    NFSv4 ACLs on Linux:

    1. Implement NFSv4 ACLs by storing the ACLs on the file system (as an
       extended attribute, or in a special file).
        Pros: Can support NFSv4 ACLs while keeping all the code changes in
              the NFS code and not needing to coordinate with the 
underlying
              file systems.  This approach helps when a Linux system is
              configured as NFS server without local access (similar to 
NAS
              appliance).
        Cons: The NFSv4 ACLs can not be used by the local users.

    2. Standardize the ACL interface with the underlying file system, and
       support NFSv4 ACLs only when the underlying file system supports 
NFSv4
       style ACLs.
        Pros: Development work is involved in NFS area only for the NFS
              developers.  Can support NFSv4 ACLs on the file systems 
which
              currently support NFSv4 style ACLs.
        Cons: Need to involve file systems developers to implement NFSv4 
ACLs.

    3. Select mostly used file systems and implement NFSv4 ACLs on both 
NFS
       and underlying file systems.
        Pros: Will be having control on the complete implementation
        Cons: Involved in extensible development time.  Need to monitor 
the
              changes to the underlying file systems and make sure no 
impact
              to the ACLs implementation.

    4. Map POSIX ACLs to NFSv4 ACLs
        Pros: Minimal development time to verify the existing 
implementation
              and improve/correct where ever possible to reduce the
              imperfectness.
        Cons: Can not use full range of NFSv4 ACLs.  Weak access controls.


    Note: The design of the NFSv4 ACL implementation need to be developed 
based
    on the decision of which approach is considered.

IV. References:
    1. RFC3530 (Network File System (NFS) version 4 Protocol)
    2. POSIX 1003.1e draft
    3. ACLs wiki page (http://wiki.linux-nfs.org/index.php/ACLs)

Thanks.

Regards,
Prasad Potluri
email: pvp at-sign us dot ibm dot com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://linux-nfs.org/pipermail/nfsv4/attachments/20060808/f00d208d/attachment.htm