2. In the beginning: "Traditional" Unix
Permissions
Write
Execute
Read
Not permitted
drwxr-x---
Other
User
Group
3. Playing Nice With Other (Unix) Users
Some tactics:
● drwxrws---: Use setgid bit to force files and
directories created within a directory to inherit its group
id, rather than be assigned user's primary group id. (c.
1972?)
● umask 002: Don't limit group permissions, or
read/execute permissions for others. (c. 1982?)
● drwxrwxrwt: Only the item's owner, directory's owner,
or root can rm or mv contained files. (c. 1986)
● User private groups: Group containing single user,
allows private files when setting umask 002. (Red Hat
c. 2002)
Take dates above with a giant grain of salt, they could be way off.
4. POSIX.1e ACLs
● Allow setting permissions for multiple users and groups
per file.
● Set explicit defaults (beyond the setgid bit).
user::rwx
user:aleonard:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:aleonard:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
5. Meanwhile, in Redmond...
NTFS ACLs:
Standard Permissions Advanced Permissions
● Modify ● Full Control
● Read & Execute ● Traverse Folder/Execute
● Read File
● Write ● List Folder/Read Data
● List Folder Contents ● Read Attributes
● Read Extended Attributes
● Create Files/Write Data
● Create Folders/Append Data
● Write Attributes
● Write Extended Attributes
● Delete Subfolders & Files
● Delete
● Read Permissions
● Change Permissions
● Take Ownership
6. Enter NFSv4 ACLs
A Standard, as of 2000:
http://ietfreport.isoc.org/idref/draft-falkner-nfsv4-acls/
https://tools.ietf.org/html/rfc3010
https://tools.ietf.org/html/rfc3530
# file: .
# owner: root
# group: bifx
group:bifx:rwxpDdaARWcCos:fd----:allow
owner@:rwxp--aARWcCos:------:allow
group@:rwxp--a-R-c--s:------:allow
everyone@:r-x---a-R-c--s:------:allow
● Each Access Control Entry (ACE) is made up of four parts: identifier,
access rights, flags, type (allow, deny, audit, alarm).
● ACEs are traversed in order.
● Access rights are NTFS compatible.
8. But: ACLs Aren't All Rainbows and
Unicorns
Assuming the trade-off of flexibility for additional complexity
is acceptable:
● Does your file system support them? Do your clients?
● Tools to manipulate ACLs are inconsistent and
sometimes inefficient.
● Does your backup software preserve ACLs?
● Do your everyday file system utilities handle them
correctly?
● Does your vendor understand them? How buggy is
their implementation?
● How do new-style ACLs interact with legacy permission
schemes?
9. Specifics: Seattle BioMed NAS
Environment
● NetApp
○ NFSv3/SMBv2
○ Mix of "office" and "science" data.
○ Home directories, group shares.
● FreeBSD/ZFS
○ ZFS v28
○ NFSv3, NFSv4/SMBv1
○ Serves NFSv4 via newnfs
○ Uses Samba for SMB
○ Larger shares, mostly scientific data
10. Specifics: Our Client Environment
Pretty standard stuff, in order of prevalence:
● Windows Desktops - SMBv1, SMBv2
○ 7, XP
○ 2000, NT4, sigh.
● OS X - SMB, no NFS
● Linux - NFSv3, NFSv4
○ CentOS
○ Ubuntu
11. Details: ACLs and NetApp
● NetApp has three different security modes
you can choose from at a volume or qtree
level.
○ "unix" mode: Unix-style permission bits.
○ "ntfs" mode: "For CIFS requests, Windows NT permissions
determine user access. For NFS requests, the filer generates and
stores a set of UNIX-style permission bits that are at least as
restrictive as the Windows NT permissions. The filer grants NFS
access only if the UNIX-style permission bits allow the user access."
○ They also have a third "mixed" mode, but nobody
seems to use it: "A file's security style depends on whether the
permission was last set from CIFS or NFS."
● (We're not using NFSv4 on NetApp today.)
○ http://www.netapp.com/us/communities/tech-ontap/nfsv4-0408.html
12. Details: ACLs and ZFS
ZFS has native NFSv4 ACLs. Important issue:
● What happens to an NFSv4 ACL when you chmod(2) is
important. If a file has an NFSv4 ACL, do you:
○ Edit only the file's mode ("passthrough")?
○ Remove any NFSv4 ACL ("discard")?
○ Do something in-between ("groupmask")?
○ Let the admin decide on a per-file system basis?
On ZFS, this is controlled by the "aclmode" property. Sun removed this shortly
before the Oracle acquisition, enforcing "discard" on all ZFS file systems;
however, FreeBSD and Illumos have added "aclmode" back.
http://arc.opensolaris.org/caselog/PSARC/2010/029/20100126_mark.shellenbaum
13. Usage notes: User mapping matters
You can't share files across platforms if you
can't map identities across platforms.
We use Active Directory as our source of truth
for users and groups; NetApp and FreeBSD
systems access this information using LDAP.
14. Usage notes: General notes
● Simple permissions solve most of our use
cases
○ User home directories are on NetApp, using unix-
mode, 0700 permissions.
○ Ntfs-mode qtrees work well for most groups.
○ Many of our complex permission structures are
SMB-only and therefore use ntfs-mode.
○ For those that need them, unix-mode qtrees are
often enough.
● For everything else, there's NFSv4 ACLs on
ZFS.
15. Usage notes: NetApp + ntfs-mode
● What you see with an ntfs qtree over NFS is often not
what you get:
$ ls -ld somedir
drwxrwxrwx 40 root root 8192 Mar 16 10:45 somedir
$ cd somedir
-bash: cd: somedir: Permission denied
● Some apps try to be good citizens and check
permissions before carrying out an action, and then fail.
Others complain when they can't set permissions within
an ntfs-mode qtree.
○ Setting cifs.ntfs_ignore_unix_security_ops (silently
discard NFS permission operations) and nfs.
ntacl_display_permissive_perms (displayed permissions are
based on the maximum access granted to any user) to 'on'can help
here.
16. Usage notes: NetApp + unix-mode
For simple configurations, these cifs shares
flags may get you what you need:
Make created files belong to a group:
-forcegroup <groupname>
Set initial permissions of newly created files and directories:
-umask <mask>
-dir_umask <mask>
-file_umask <mask>
17. Usage notes: ZFS on which
operating system?
We're using FreeBSD 8-STABLE, as we often
need fixes before they wind up in a -RELEASE.
The freebsd-fs@freebsd.org and freebsd-
stable@freebsd.org mailing lists have been
indispensable.
On the Solaris side of ZFS, there's always Oracle Solaris 11.
As far as Ilumos, Nexenta is always an option,
and I hear there's neat stuff being built on OmniOS.
There's also ZFS-on-Linux.
18. Usage Notes: ZFS file system
properties
We generally set permissions at the top of a
share, and have them inherited down into the
share, so we:
zfs set aclinherit=passthrough-x
Inherits all inheritable ACL entries without modification, but
inherit execute permission only if the file creation mode
specifies it.
zfs set aclmode=passthrough
When chmod(2) is called, "no changes are made to the
ACL other than creating or updating the necessary ACL
entries to represent the new mode of the file or directory."
19. Usage notes: Samba configuration -
simple permissions
We frequently use this idiom when configuring Samba
shares, roughly equivalent to umask 007 and a setgid
directory under NFS:
# Bitwise AND file/directory permissions with these masks:
create mask = 0660
directory mask = 2770
# File/directory permission bits that will always be set:
force create mode = 0660
force directory mode = 2770
# Assign group:
force group = "somelab"
# Limit permission bits that can be modified from Windows client -
# these are forced on:
force security mode = 0660
force directory security mode = 2770
20. Usage notes: Samba configuration -
complex ACLs
Set ACLs using native tools on ZFS as needed.
In smb.conf, remove force group, adjust
mask and mode settings as appropriate... and
let the NFSv4 ACLs at the file system level do
the rest.
(Remember: Samba is just another application
accessing files - v4 ACLs, including inheritance,
are still applied.)
21. Usage notes: Samba on FreeBSD/ZFS config to
allow ACL manipulation from Windows
We haven't heavily used this, but it seems to work.
Build Samba WITH_ACL_SUPPORT=true from FreeBSD ports; add the
following to smb.conf:
Global config:
unix extensions = no
Within a share definition:
nt acl support = yes
inherit acls = no
map acl inherit = yes
vfs objects = zfsacl
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = yes
22. Usage notes: Users increasingly
want to manipulate their own ACLs
In general, our users haven't wanted to
understand or manage their own ACLs, so IT
has done it for them. However, we now have
one group of users - an internal service
provider - that wants to actively manage their
own ACLs on a wide scale.
● They use either nfs4_setfacl on Linux, or
an IT-supplied script to adjust permissions.
● This is a fairly new development, so it's
unclear what pitfalls await.
23. Closing: NFSv4 in 2012
Despite being 12 years old, NFSv4 isn't widely-
or well-supported. Commercial vendors don't
dedicate more resources to it because users
aren't using it heavily; users don't use it heavily
because vendors aren't dedicating resources to
it.
As a consequence, the best implementations
and support today seem to be Open Source.
