If I'm using NFSv4 ACLs on FreeBSD, and I change the ACLs on a directory in a way that affects the inherited ACLs of its child files+dirs (and potentially might cascade and affect the children/grandchildren of its child dirs), at what point is that recalculation done, and how is the process managed?
Concrete example: Suppose I have an existing dir hierarchy, and I want to add a new ACL that adds a denial, or removes an allow, for some group. I execute one of the following commands for the top level directory:
setfacl -a 0 g:mygroup:dD:fd:deny /path_to_dir
setfacl -x g:mygroup:dD:fd:allow /path_to_dir
But it's not clear how ACL propagation works, when it actually takes place, or even whether it happens (or needs to happen) from the docs. Also if files are copied with the wrong ACLs, I can't find a way to recalculate ACLs from the parent, or even whether such a thing exists.
My questions on this example:
- Is simply executing a
setfaclcommand enough to trigger propagation of these rules, and (if needed) "cascade" them down the hierarchy, causing permissions/ACLs on all contained objects to be updated?
- Alternatively, is runtime recalculation during the
setfaclcommand unnecessary, perhaps because FreeBSD calculates ACLs "on the fly" from the top directory down during any file access, rather than pre-emptively calculating and storing effective ACLs and updating them for all affected objects whenever ACLs change?
- If FreeBSD doesn't calculate downwards when the command is executed, and doesn't calculate them "on the fly", when does the new ACL become effective throughout the tree, and/or what must be done to make it effective further down the tree?
- If files/dirs exist with incorrect ACLs, is the only way to fix it, to make all ACLs on these files explicitly defined (and forego inheritance)?
Answers that wouldn't be useful:
If propagation is an issue and workarounds are needed, there are a couple of possible answers that might come to mind that don't really answer the question (for me). To help focus good answers, I'm noting them here as being non-answers:
- I'm aware that I could set explicit ACLs manually, using
find /path_to_dir -exec setfaclto work around any propagation/recalculation issue. But this isn't helpful, because it means replacing inherited ACLs by explicit ACLs throughout. On many clients (Windows especially), explicit/inherited ACLs have different priorities, so this changes how ACLs are calculated, and ACLs that worked before might work differently afterwards. Too easy to break things. Also means that auditing permissions can't just check for files+dirs that aren't inheriting, because too much ACL setup will have moved to non-inherited and need case by case checking. Basically "yuck" :)
- I'm also aware that another possible answer might be to copy all affected files/dirs. to a new, parallel location in the same file system, because copying can be forced to create ACLs from scratch and those would be based on current ACLs of the top dir. This isn't applicable since it's usually unrealistic in reality to ask for an entire file system to be duplicated just to change an ACL. Also too easy to break things, disrupt things, messes round with
rsync/backups/snapshots (if using zfs with snapshots).
I'd also like to keep to FreeBSD here, because different systems probably check and update acls very differently and the current system I need an answer on, is FreeBSD based.