Lisa Week's Weblog

NFSv4 and ZFS ACLs

Who I am:

Well, since this is my first blog entry, I suppose I should introduce myself...
I am Lisa Week.  I've been working at Sun Microsystems for almost 4.5 years.  I graduated with a Bachelor of Science Degree in Computer Engineering from the South Dakota School of Mines and Technology (SDSM&T).  I started working for Sun as an intern and was offered a full-time position after I graduated.  When I came to Sun as a full-time employee I was in the Data Resource Management Group.  We developed and maintained GUIs and APIs for things like file system mounts and shares and the Solaris Volume Manager (actually, I didn't work on this much).  I then went on to develop a CIM/WBEM provider for NFS along with Evan.  This is what got me interested in and introduced me to NFS.  I am now having fun and being challenged by working on NFSv4.  As of late, I have been focusing most of my time on NFSv4 ACLs, therefore, this is what I'll be writing about for my maiden blog...

Thanks for reading and I hope you come back...

What I've been up to:

Before going much further, I'd like to cover what ACLs are for those of you who might not know.  ACLs are Access Control Lists.  They give users the ability to have fine-grained access control over their files and directories.  This includes giving users the ability to specify access to their files in a simple, meaningful way.

Over the last several months, I've been doing a lot of work with NFSv4 ACLs.  First, I worked with Sam to get NFSv4 ACL support into Solaris 10.  The major portion of this work involved implementing the pieces to be able to pass ACLs over-the-wire as defined by section 5.11 of the NFSv4 specification (RFC3530) and the translators (code to translate from UFS (or also referred to as POSIX-draft) ACLs to NFSv4 ACLs and back).  At that point, Solaris was further along with regard to ACLs than it ever had been, but was still not able to support the full semantics of NFSv4 ACLs.  So...here comes ZFS!

After getting the support for NFSv4 ACLs into Solaris 10, I started working on the ZFS ACL model with Mark and Sam.  So, you might wonder why a couple of NFS people (Sam and I) would be working with ZFS (Mark) on the ZFS ACL model...well that is a good question.   The reason for that is because ZFS has implemented native NFSv4 ACLs.  This is really exciting because it is the first time that Solaris is able to support the full semantics of NFSv4 ACLs as defined by RFC3530.

In order to implement native NFSv4 ACLs in ZFS, there were a lot of problems we had to overcome.  Some of the biggest struggles were ambiguities in the NFSv4 specification and the requirement for ZFS to be POSIX compliant.  These problems have been captured in an Internet Draft submitted by Sam and me on October 14, 2005.

ACLs in the Computer Industry:

What makes NFSv4 ACLs so special...so special to have the shiny, new ZFS implement them?  No previous attempt to specify a standard for ACLs has succeeded, therefore, we've seen a lot of different (non-standard) ACL models in the industry.  With NFS Version 4, we now have an IETF approved standard for ACLs.

As well as being a standard, the NFSv4 ACL model is very powerful.  It has a rich set of inheritance properties as well as a rich set of permission bits outside of just read, write and execute (as explained in the Access mask bits section below).  And for the Solaris NFSv4 implementation this means better interoperability with other vendor's NFSv4 implementations.

ACLs in Solaris:

Like I said before, ZFS has native NFSv4 ACLs!  This means that ZFS can fully support the semantics as defined by the NFSv4 specification (with the exception of a couple things, but that will be mentioned later).

What makes up an ACL?

ACLs are made up of zero or more Access Control Entries (ACEs).  Each ACE has multiple components and they are as follows:

1.) Type component:
        The type component of the ACE defines the type of ACE.  There
        are four types of ACEs: ALLOW, DENY, AUDIT, ALARM.


        The ALLOW type ACEs permit access.
        The DENY type ACES restrict access.
        The AUDIT type ACEs audit accesses.
        The ALARM type ACEs alarm accesses.

        The ALLOW and DENY type of ACEs are implemented in ZFS.
        AUDIT and ALARM type of ACEs are not yet implemented in ZFS.

        The possibilities of the AUDIT and ALARM type ACEs are described below.  I
        wanted to explain the flags that need to be used in conjunction with them before
        going into any detail on what they do, therefore, I gave this description its own
        section.

2.) Access mask bits component:
        The access mask bit component of the ACE defines the accesses
        that are controlled by the ACE.

        There are two categories of access mask bits:
        1.) The bits that control the access to the file
                i.e. write_data, read_data, write_attributes, read_attributes
        2.) The bits that control the management of the file
                i.e. write_acl, write_owner

        For an explanation of what each of the access mask bits actually control in ZFS,
        check out Mark's blog.

3.) Flags component:
        There are three categories of flags:
        1.) The bits that define inheritance properties of an ACE.
                i.e. file_inherit, directory_inherit, inherit_only,
                      no_propagate_inherit
                Again, for an explanation of these flags, check out Mark's blog.
        2.) The bits that define whether or not the ACE applies to a user or group
                i.e. identifier_group
        3.) The bits that work in conjunction with the AUDIT and ALARM type ACEs
                i.e. successful_access_flag, failed_access_flag.
                ZFS doesn't support these flags since they don't support AUDIT and
                ALARM type ACEs.

4.) who component:
        The who component defines the entity that the ACE applies to.

        For NFSv4, this component is a string identifier and it can be a user, group or
        special identifier (OWNER@, GROUP@, EVERYONE@).  An important thing to
        note about the EVERYONE@ special identifier is that it literally means everyone
        including the file's owner and owning group.  EVERYONE@ is not equivalent to
        the UNIX other entity.  (If you are curious as to why NFSv4 uses strings rather
        than integers (uids/gids), check out Eric's blog.)

        For ZFS, this component is an integer (uid/gid).

What do AUDIT and ALARM ACE types do?

The AUDIT and ALARM type of ACES trigger an audit or alarm event upon the successful or failed accesses depending  on the presence of the successful/failed access flags  (described above) as defined in the access mask bits of the ACE.  The ACEs of type AUDIT and ALARM don't play a role when  doing access checks on a file.  They only define an action to happen in the event that a certain access is attempted.

For example, lets say we have the following ACL:


The first ACE affects the access that user, "lisagab", has to the  file.  The second ACE says if user, "lisagab", attempts to access this file for writing and fails, trigger an alarm event.

One important thing to remember is the fact that what we do in the event of auditing or alarming is still undefined.  Although, you can  think of it like this: when the access in question happens, auditing could be the logging the event to a file and alarming could be the sending of an email to an administrator.

How is access checking done?

To quote the NFSv4 specification:

 To determine if a request succeeds, each nfsace4 entry is processed
 in order by the server. Only ACEs which have a "who" that matches
 the requester are considered. Each ACE is processed until all of the
 bits of the requester's access have been ALLOWED. Once a bit (see
 below) has been ALLOWED by an ACCESS_ALLOWED_ACE, it is no longer
 considered in the processing of later ACEs. If an ACCESS_DENIED_ACE
 is encountered where the requester's access still has unALLOWED bits
 in common with the "access_mask" of the ACE, the request is denied.

What this means is:

The most important thing to note about access checking with NFSv4 ACLs is that it is very order dependent.  If a request for access is made, each ACE in the ACL is traversed in order.  The first ACE that matches the who of the requester and defines the access that is being requested is honored.

For example, lets say user, "lisagab", is requesting the ability to read the data of file, "foo" and "foo" has the following ACL:


lisagab would be allowed the ability to read_data because lisagab is covered by "everyone@".

Another thing that is important to know is that the access determined is cumulative.

For example, lets say user, "lisagab", is requesting the ability to read and write the data of file, "bar" and "bar" has the following ACL:


lisagab would be allowed the ability to read_data and write_data.

How to use ZFS/NFSv4 ACLs on Solaris:

Many of you may remember the setfacl(1) and getfacl(1) commands.  Well, those are still around, but won't help you much with manipulating ZFS or pure NFSv4 ACLs.  Those commands are only capable of manipulating the POSIX-draft ACLs as implemented by UFS.

As a part of the ZFS putback, Mark has modified the chmod(1) and ls(1) command line utilities in order to manipulate ACLs on Solaris.

chmod(1) and ls(1) now give us the ability to manipulate ZFS/NFSv4 ACLs.  Interestingly enough, these utilities can also manipulate POSIX-draft ACLs so, now there is a one stop shop for all your ACL needs.

The End:

I would like to say congratulations to the ZFS team and thanks for the t-shirt.