ACLs on Shares
By dougm on Feb 18, 2009
With build 109 of Open Solaris, a new feature has been added to the CIFS server - ACLs on Shares.
ACLs on shares bring better compability with the Microsoft implementation and allow more control over access than the CIFS server previously supported. Basically, it is now possible to set and modify ACLs on the individual share resources for CIFS. That is, if you create a CIFS resource called "My Files" on a ZFS dataset pool/my-files, you can add another layer of ACL support at the share level. This is done using standard Open Solaris utilities (chmod to modify and ls to view). There is now a new file system object that holds the ACLs for ZFS file systems. In the case of "My Files", the root of the file system is /pool/my-files. If you "cd /pool/my-files/.zfs/shares", you will now see a file object with the name "my_files".
This file object is only used to hold the ACL values for the share. It cannot be renamed or removed using file system utilities. Only chmod and ls (or other utilities that deal with ZFS ACLs) work on it.
If you create a second resource (CIFS share) on the same path, that share name will also appear in the same directory. Each one of these objects may have different ACL specifications. The result is that you could have one share that is read/write while the other is read-only.
ACLs on shares are essentially used to remove access that the file system may be providing. When used in conjunction with the host-based access control, there is a great deal of fine level control over access available.
Most of the time there won't be a need for ACLs on the individual shares, but they do provide some flexibility that can be useful. One possibility is to provide a standard, read-only share for a path that is the one normally available. A second share defined for the same path could have read-write set for some users in order for them to do maintenance on the share.
Combined with the ACLs on the underlying file system and the coarser level, host-based access control (the rw/ro/none properties on a resource), access can be controlled with quite a bit of detail. One warning is that with this much control, it is also possible to setup shares that you cannot access, so be careful and plan things out carefully.