ZFS trouble with ACLs (setfacl)

patpro

patpro

Hello,

I'm trying to give a user (splunk) read access to everything inside /var/log. I've set some ACLs but it's not enough:

Bash: 
# getfacl /var/log
# file: /var/log
# owner: root
# group: wheel
      group:splunk:r-----a-R-c---:fd-----:allow
            owner@:rwxp--aARWcCos:-------:allow
            group@:r-x---a-R-c--s:-------:allow
         everyone@:r-x---a-R-c--s:-------:allow

If I understand correctly this should be enough so that new files created inside /var/log get inherited ACL that allows users in splunk group to read those new files. But actually it is not:
Bash: 
# ls -l maillog
-rw-r-----  1 root  wheel  1053981 Sep 25 10:35 maillog

Now that I'm trying to change or add more access lists, I'm stuck with an error:

Bash: 
# setfacl -dm g:splunk:read_set:fd:allow /var/log
setfacl: /var/log: there are no default entries in NFSv4 ACLs

I guess I've failed somewhere. Any hint?
 
patpro said:
Code: 
Bash:
# ls -l maillog
-rw-r-----  1 root  wheel  1053981 Sep 25 10:35 maillog
Click to expand...


Testing here on a 12.1-RELEASE VM, following handbook, chapter 13.9.1. Enabling ACL Support, and setfacl(1):

set in /etc/fstab acls to the mount options (a UFS2 disk besides a root-on-ZFS on a separate disk)
executed setfacl -dm u::rwx,g::rx,o::rx,mask:rwx var , as described in setfacl(1), EXAMPLES
touch var/maillog
ls -l var
-rw-r--r--+ 1 root wheel 0 Oct 23 13:51 maillog

Handbook :"File systems with ACLs enabled will show a plus (+) sign in their permission settings:"
 
T-Daemon said:
Testing here on a 12.1-RELEASE VM, following handbook, chapter 13.9.1. Enabling ACL Support, and setfacl(1):

set in /etc/fstab acls to the mount options (a UFS2 disk besides a root-on-ZFS on a separate disk)
executed setfacl -dm u::rwx,g::rx,o::rx,mask:rwx var , as described in setfacl(1), EXAMPLES
touch var/maillog
ls -l var
-rw-r--r--+ 1 root wheel 0 Oct 23 13:51 maillog

Handbook :"File systems with ACLs enabled will show a plus (+) sign in their permission settings:"
Click to expand...
Sorry, I've overlooked the ZFS tag, my appologies.

For ZFS ACL's look in zfs(8)
 
Yeah, thanks, totally overlooked the ZFS properties about ACLs :(
I'll have a look ASAP.
 
You forgot about the execute bit to give access to the directory.

Code: 
setfacl -m 'group:splunk:r-x---a-R-c--s:-------:allow' /var/log

Are NFS/ZFS ACLs described in detail anywhere? They remain a mystery to me.
 
For NFSv4 ACLs, there is a highly detailed and definitive specification in the NFSv4 standards document, which comes out of the IETF as an RFC. About 15 years ago, I had the mis-pleasure of having to read it completely; took me about 2 weeks. No, I don't know any more concise and readable documentation, nor do I know a good document that compares POSIX ACLs to NFSv4 ACLs (I know that POSIX is sort of but not really a subset of NFS). I suspect that there are some good documents out of that group at the Univ. of Michigan that first implemented NFSv4, but those are probably still highly technical. Let me remember what they're called ... search the web for "CITI" and NFS and ACL, and you'll find it.

Personal remark: I hate ACLs. If I have to protect a file, I'd rather punch it onto a deck of cards, put it into a safe, and defend it at gunpoint; that's easier and safer than using ACLs, because lead poisoning is easier to cure than brain damage. And I don't like EAs (extended attributes) and byte-range locking either.
 
POSIX ACLs are very simple – it is a generalization of the traditional UNIX rwx permission bits applicable per individual user or group. There are also the default permissions that are applied to newly created entries and the “mask” value that filters out all additional permissions; the purpose of the latter remains unknown (newer versions of getfacl print a warning if mask chops any bits).

Revenons a nos moutons, CITI's manual sheds some light on the topic except that some of the flags do not correspond to what getfacl prints on ZFS (for example there is no capital R). I couldn't find anything useful in Solaris manuals either, although I might try setting up a NFSv4 export over ZFS on Solaris and then trying to reverse engineer the permission by manupulating them with the nfs4_setfacl tool.
 
Matlib is right, it's the execute bit you are missing. This is the process I use to set ACLs recursively. Possibly overkill but it works with Samba also and ensures you get consistency.


I first reset everything to their defaults (makes it eaiser to remove public access etc.)

find . -exec setfacl -b {} \;


I then remove most deafults. From memory, I think the owner one doesn't work, you probably don't want that changed anyway.

find . -exec setfacl -x group@:r-x---a-R-c--s:-------:allow {} \;
find . -exec setfacl -x everyone@:------a-R-c--s:-------:allow {} \;
find . -exec setfacl -x owner@:r-x---aARWcCos:-------:allow {} \;


Then to grant readonly access (to individual user).

find . -type d -exec setfacl -m user:{uid-or-name}:r-x---a-R-c---:fd----I:allow {} \;
find . -type f -exec setfacl -m user:{uid-or-name}:r-x---a-R-c---:------I:allow {} \;


To grant full control (to group).

find . -type d -exec setfacl -m group:{gid-or-name}:rwxpDdaARWc---:fd----I:allow {} \;
find . -type f -exec setfacl -m group:{gid-or-name}:rwxpDdaARWcCo-:------I:allow {} \;


"find ." assumes you are starting from your current shell location so change accordingly.
 
patpro said:
I'm trying to give a user (splunk) read access to everything inside /var/log. I've set some ACLs but it's not enough:

Bash: 
# getfacl /var/log
# file: /var/log
# owner: root
# group: wheel
      group:splunk:r-----a-R-c---:fd-----:allow
            owner@:rwxp--aARWcCos:-------:allow
            group@:r-x---a-R-c--s:-------:allow
         everyone@:r-x---a-R-c--s:-------:allow
Click to expand...
As other have pointed out you need the "x" right for the splunk group to be able to access things in the directory (same as with normal old Unix mode bits).

Now I'd recommend an ACL something like this though:

...
group:splunk:r-x---a-R-c---:-d-----:allow
group:splunk:r-----a-R-c---:f------:allow
...

Meaning that directories ("d") created in /var/log will get the "x" bit inherited
but files ("d") created will not get it set (to avoid being log files be "executable").

When working with ACLs I can recommend a tool I've created called "acltool" (pkg install acltool), it makes working with
ACLs a little bit less painful and can combine find+getfacl+setfacl in "one". I wrote it when I got tired of setfacl/getfacl and also wanted a tool that works the same on FreeBSD, Linux, Solaris & MacOS...

With acltool one could do something like:

Code: 
% acltool edac -r g:splunk:read_set:f,g:splunk:rxaRc:d /var/log
% acltool lac -v /var/log
# file: /var/log
# owner: root (0)
# group: wheel (0)
# type: directory
            owner@:rwxpDdaARWcCos:-------:allow
            group@:r-x---a-R-c---:-------:allow
      group:splunk:r-----a-R-c---:f------:allow # gid=1234
      group:splunk:r-x---a-R-c---:-d-----:allow # gid=1234
         everyone@:r-x---a-R-c---:-------:allow

(-r = apply recursively)
 
You must log in or register to reply here.
Back
Top