NFSv4 ACL recommended read-write permission sets?

fishfox

fishfox

Wondering the best way to implement basic read-write and read-only permissions for a share.

First I tried using the built in modify_set and read_set but it the read_set lacks the x bit needed to navigate directories (or at least this is my understanding with some testing).

I noticed that the octal equivalent for 7 is rwxp--aARWcCos and equivalent for 5 is r-x---a-R-c--s; should I use these permission sets as my read/write?

I am also a bit confused as the rwxp--aARWcCos octal 7 equivalent set omits delete and delete_child -- I am apparently still able to delete without these set. Can somebody explain what's going on here?

Thanks!
 
fishfox said:
Wondering the best way to implement basic read-write and read-only permissions for a share.

First I tried using the built in modify_set and read_set but it the read_set lacks the x bit needed to navigate directories (or at least this is my understanding with some testing).

I noticed that the octal equivalent for 7 is rwxp--aARWcCos and equivalent for 5 is r-x---a-R-c--s; should I use these permission sets as my read/write?

I am also a bit confused as the rwxp--aARWcCos octal 7 equivalent set omits delete and delete_child -- I am apparently still able to delete without these set. Can somebody explain what's going on here?

Thanks!
Click to expand...

The execute bit is "traverse" on directories.

I'm not sure what you mean by octal equivalents...

Also, why do you need this? Can't you just make due with users and groups? I never thought NFSv4 ACLs were a good idea to implement... too complex, not really useful... For one, if you share data, you should have a revision control system, and that version control system's archive shouldn't be shared, and if you trust someone enough to let them write to your system, you should also trust them enough not to malevolently delete data, tamper, or vandalize...

I just honestly don't see any real-world useful implementation of NFSv4 ACLs...

I know Windows uses those, and I thought they were implemented in POSIX for compatibility with NTFS file systems, but I didn't think you could implement those on an actual multiuser POSIX system... AFAICFO, it's actually something you have to turn on, and maybe even run daemons or modules for...

Why would you want to mess with that?
 
The need is simple -- I have a client that has a need for more granular permissions on a FreeNAS box. For a personal machine I agree, not much use, but this is for a business with different departments that have a need for more complex permissions in their file shares.

I did end up finding out what I needed -- this post held the information that I couldn't find in any of the official docs: NFSv4 ACL's not being respected by BSD

I'd like to find an official version of the above docs if anybody knows where I can find that.


Say I have three shares, A, B, and C.

I need to have read write and read only groups for each, so my client can provide their employees with proper permissions to the proper materials.

Setting permissions to 775 allows control of the read write behavior but allows all groups read only to all other data.

With ACLs this is easy -- I create A_rw, A_ro, B_rw, B_ro, etc. Then I just slap those groups in the ACLs. What if I need to add somebody in a pinch who doesn't belong in a group for some reason? Just add them to the ACL.

Traditional permissions are very inflexible. There is a reason why NTFS and *nix ACLs exist.

What would you propose?
 
Phishfry said:
Have you looked at this wiki at all? It is older than the post you linked to, but it is from the developer who implemented it.
https://wiki.freebsd.org/NFSv4_ACLs
Click to expand...

I have, and while it links to a very involved NFSv4 spec, it doesn't give a quick readout of what each permission bit actually means in practice.

I did figure out what works for me, which I'll put below in case it is useful to anybody:

rw: rwxpaARWcs
ro: rxaRcs
na: aRcs (no access -- these mirror the effective '0' octal permissions)

Things to note:

The omissions are more important than the inclusions here:

d and D allow you to delete data which you have no ownership of.

C allows you to edit ACLs to your preference with no ownership, which in my environment a read-write user should not be able to do (can't have users locking themselves or others out of shares that should have standard permissions).

Given that I boiled down the settings I wanted to use, I wrote a quick and hacky command to put into my ~/bin dir to lighten the keystrokes needed. Now I can just type ezacl group5 ro dir2 to grant read only permissions, for example, to group5 on dir2, and so forth.
Code: 
#!/bin/bash
group="$1"
perm="$2"
file="$3"
#check number of args
if [ $# -eq 0 ] || [ $# -gt 3 ]; then
echo 'syntax: ezacl <group> <rw|ro|na> <dir>'
exit 0
fi
#check group valid
if [ ! $(getent group "$group") ]; then
(>&2 echo 'invalid group!')
exit 1
fi
#check file valid
if [ ! -d "$file" ] && [ ! -f "$file" ]; then
(>&2 echo 'invalid dir!')
exit 1
fi
#perform op, if valid
if [ "$perm" = "rw" ]; then
if [ -d "$file" ]; then
echo "running: setfacl -m g:$group:rwxpaARWcs:fd:allow $file"
setfacl -m g:"$group":rwxpaARWcs:fd:allow "$file"
else
echo "running: setfacl -m g:$group:rwxpaARWcs::allow $file"
setfacl -m g:"$group":rwxpaARWcs::allow "$file"
fi
elif [ "$perm" = "ro" ]; then
if [ -d "$file" ]; then
echo "running: setfacl -m g:$group:rxaRcs:fd:allow $file"
setfacl -m g:"$group":rxaRcs:fd:allow "$file"
else
echo "running: setfacl -m g:$group:rxaRcs::allow $file"
setfacl -m g:"$group":rxaRcs::allow "$file"
fi
elif [ "$perm" = "na" ]; then
if [ -d "$file" ]; then
echo "running: setfacl -m g:$group:aRcs:fd:allow $file"
setfacl -m g:"$group":aRcs:fd:allow "$file"
else
echo "running: setfacl -m g:$group:aRcs::allow $file"
setfacl -m g:"$group":aRcs::allow "$file"
fi
else
(>&2 echo 'invalid permission code!')
exit 1
fi
fi
 
Last edited:
You must log in or register to reply here.
Back
Top