Skip to main content

ZFS and NFSv4 ACL’s

I've been doing granular file access control lists since Netware 2.0. I'm used to being able to specify (for example) permissions such that a file can be modified, but not renamed or deleted, or setting permissions on a file so that it can be executed, but not read - (Yes, Netware could do that). And of course, it's obvious that more than one user or group permission should be allowable. I'm also used to having some control over inheritance, so that I can 'kneecap' permissions on a nested directory.

Obviously I've been very unimpressed with Unix's trivial rwxr-x--- style permissions. Sun band-aided the decades old rwxr-x--- up with POSIX getfacl and setfacl. That was a start. We now have NFSv4 style ACL’s on ZFS. It looks like they are almost usable.

For an experiment, I decided to clean up a few 'home directories' where the existing permissions are a mess of randomness left over from a decade of ufsdump/ufsrestore, POSIX ACL's, tar, cpio, pax, samba, rsync and who knows what else. Here's my attempt at simple ACL's on an OpenSolaris ZFS volume.

Specific requirements:

  • Owner gets the equivalent of 'full control'.
  • Group gets the equivalent of 'read only'.
  • Everyone gets nada.
  • Newly created files get predictable permissions

To ensure predictable permissions, I want inheritance in some form or another such that:

  • New files are automatically created to allow owner the equivalent of read, write, create, delete, modify, including ACL's and attributes, but without the ‘execute’ bit set.
  • New files are automatically created to allow group 'read-only' but without the ‘execute’ bit set.
  • New directories are automatically created to allow the owner the equivalent of read, write, create, delete, modify, browse, including ACL's and attributes.
  • New directories are automatically created as group read and browse.
  • New files and directories are automatically created with no permissions for ‘everyone’

Keep in mind that the newest ACL implementation needs the Solaris version of ls, chmod, etc., rather than the default gnu versions that ship with OpenSolaris. Also – I’m using Solaris ‘CIFS’, not samba.

First I set:

zfs set aclinherit=passthrough-x  filesystem

passthrough-x appears to mean 'only inherit the 'execute' bit if the application specifically requests the bit when the file is created'. At least that's what it appears to mean.

Then I fixed existing files. Note that I wanted to touch only the files (not the directories), hence the 'find'.

find . -type f  -exec /usr/bin/chmod A=\
owner@:rw-pdDaARWc--s::allow,\
group@:r-----a-R-c---::allow,\
everyone@:full_set::deny {} \;

Explanation:

find . -type f  \
-exec /usr/bin/chmod A=\
<= The 'A=' resets all ACL's rather than adding more ACL's
owner@:rw-pdDaARWc--s::allow,\ <= Set file owner to 'full control' minus the execute bit.
group@:r-----a-R-c---::allow,\ <= Set group to 'read'.
everyone@:full_set::deny {} \;  <= Set everyone else to 'deny all'.

This has a side effect of removing the execute bit from executable files. My standard policy is 'no executable files in home directories'. Those smart enough to know what the 'x' bit is are smart enough to know how to fix what just  broke. I wouldn’t do this in directories full of executable files.

Lastly, I tweaked the directories. Setting inheritance ensures that new files and directories have the desired ACL's:

find . -type d -exec /usr/bin/chmod  A=\
owner@:full_set:d:allow,\
owner@:rw-pdDaARWc--s:f:allow,\
group@:r-x---aAR-c---:d:allow,\
group@:r-----a-R-c---:f:allow,\
everyone@:full_set:fd:deny {} \;

Explanation:

find . -type d \
-exec /usr/bin/chmod  A=\
<= The 'A=' resets all ACL's rather than adding more ACL's
owner@:full_set:d:allow,\ <= Set directory owner to 'full control' with inheritance for newly created directories, including the execute bit.
owner@:rw-pdDaARWc--s:f:allow,\ <= Set directory owner to 'full control' with inheritance for newly created files, excluding the execute bit.
group@:r-x---aAR-c---:d:allow,\ <= Set group  to 'rx-' with inheritance for newly created directories
group@:r-----a-R-c---:f:allow,\ <= Set group to 'r' with inheritance for newly created files
everyone@:full_set:fd:deny {} \; <= Kneecap everyone else

In theory, new files will be created with the equivalent of rw-r-----, new directories will be created equivalent to rwxr-x---.

Maybe.

Helpful docs:

Comments

  1. I have had some trouble managing ACLs with CIFS, especially when touching files from both the Solaris side and the Windows side.

    I'd love to read a follow-up on a few simple tests to verify if it worked as you expected. Any unexpected results?
    .

    ReplyDelete

Post a Comment

Popular posts from this blog

Cargo Cult System Administration

“imitate the superficial exterior of a process or system without having any understanding of the underlying substance” --Wikipedia During and after WWII, some native south pacific islanders erroneously associated the presence of war related technology with the delivery of highly desirable cargo. When the war ended and the cargo stopped showing up, they built crude facsimiles of runways, control towers, and airplanes in the belief that the presence of war technology caused the delivery of desirable cargo. From our point of view, it looks pretty amusing to see people build fake airplanes, runways and control towers  and wait for cargo to fall from the sky.The question is, how amusing are we?We have cargo cult science[1], cargo cult management[2], cargo cult programming[3], how about cargo cult system management?Here’s some common system administration failures that might be ‘cargo cult’:Failing to understand the difference between necessary and sufficient. A daily backup is necessary, b…

Ad-Hoc Verses Structured System Management

Structured system management is a concept that covers the fundamentals of building, securing, deploying, monitoring, logging, alerting, and documenting networks, servers and applications. Structured system management implies that you have those fundamentals in place, you execute them consistently, and you know all cases where you are inconsistent. The converse of structured system management is what I call ad hoc system management, where every system has it own plan, undocumented and inconsistent, and you don't know how inconsistent they are, because you've never looked.

In previous posts (here and here) I implied that structured system management was an integral part of improving system availability. Having inherited several platforms that had, at best, ad hoc system management, and having moved the platforms to something resembling structured system management, I've concluded that implementing basic structure around system management will be the best and fastest path to …

The Cloud – Provider Failure Modes

In The Cloud - Outsourcing Moved up the Stack[1] I compared the outsourcing that we do routinely (wide area networks) with the outsourcing of the higher layers of the application stack (processor, memory, storage). Conceptually they are similar:
In both cases you’ve entrusted your bits to someone else, you’ve shared physical and logical resources with others, you’ve disassociated physical devices (circuits or servers) from logical devices (virtual circuits, virtual severs), and in exchange for what is hopefully better, faster, cheaper service, you give up visibility, manageability and control to a provider. There are differences though. In the case of networking, your cloud provider is only entrusted with your bits for the time it takes for those bits to cross the providers network, and the loss of a few bits is not catastrophic. For providers of higher layer services, the bits are entrusted to the provider for the life of the bits, and the loss of a few bits is a major problem. The…