The setfacl command is missing recursive functionality. The proposed and attached patch implements said functionality. Included in the patch is also an enhancement to the -k switch. Solaris allows for zero-number ACL entries on objects stored in ZFS datasets via `chmod A= /path/to/file". FreeBSD does not support zero-number ACL entries so I give owner@ full permissions. This enhancement depends upon another bug report I sent that allows use of ACL sets (read_set, write_set, modify_set, full_set) in ZFS NFSv4 ACLs. Fix: Patch included. Patch attached with submission follows:
Responsible Changed From-To: freebsd-bugs->trasz I'll take it.
Hi, I tried the patch on a 9.0-RELEASE and it applies without any problems. On 9.1-STABLE (r246451) however, that patch had to be adjusted a bit (see the new patch below). Attached, you may also find the patch for the man page. Feel free to modify if necessary. PS: Any chance this will be imported? -- Claudiu Vasadi System Administrator myphotobook Oranienstraße 183 10999 Berlin Germany Tel.:+49 (0)30 616 508 120 Fax: +49 (0)30 616 508 250 c.vasadi@myphotobook.de Authorised Executives: Vanessa Dill Trade Register: HRB 94377, Berlin
Disown. I don't even remember how that code works anymore. One potential problem with this code that it used fts to build a list of all paths in the tree, instead of using fts to iterate over the tree, and that could fail due to out of memory condition. That said, it doesn't look critical, and that's also how setfacl works right now.
Created attachment 151059 [details] Add recursive support to setfacl(1) Manpage still needs to be updated. This patch works against 11-CURRENT.
Is testing and work on this patch still in progress? The inability to recursively set ACLs on FreeBSD is quite an annoyance and I was going to open my own bug report on it when I found this one already open.
The patch I submitted in December of last year works well in HardenedBSD.
Created attachment 177998 [details] Add recurisve support to setfacl(1) Update the patch to reflect latest HEAD.
Hey Allan, have you had a chance to look at this?
This is open for review in https://reviews.freebsd.org/D9096, and it is currently blocked on issues raised in that review.
Updated patch in review at https://reviews.freebsd.org/D14934
A commit references this bug: Author: emaste Date: Tue Apr 10 23:29:57 UTC 2018 New revision: 332396 URL: https://svnweb.freebsd.org/changeset/base/332396 Log: setfacl: add recursive functionality Add a -R option to setfacl to operate recursively on directories, along with the accompanying flags -H, -L, and -P (whose behaviour mimics chmod). A patch was submitted with PR 155163, but this is a new implementation based on comments raised in the Phabricator review for that patch (review D9096). PR: 155163 Submitted by: Mitchell Horne <mhorne063@gmail.com> Reviewed by: jilles MFC after: 2 weeks Relnotes: Yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D14934 Changes: head/bin/setfacl/setfacl.1 head/bin/setfacl/setfacl.c head/bin/setfacl/setfacl.h head/bin/setfacl/util.c
(In reply to commit-hook from comment #11) The new version of the recursive patch does not remove the inheritance flags from files, so when you do something like: setfacl -R -m everyone@:full_set:fd:allow /some/path You get the following error: setfacl: /usr/src2/tools/tools/track/track.sh: acl_set_link_np() failed: Invalid argument
(In reply to Shawn Webb from comment #12) Are you sure this isn't an existing issue? After enabling NFSv4 ACLs on UFS I get the same error both pre and post patch, regardless of -R.
(In reply to Mitchell Horne from comment #13) It is an existing issue that was addressed in the original recursive setfacl patch. The reason to address this issue is that by using recursive functionality, users will now be applying unwittingly inheritance flags on objects (files) in which inheritance doesn't apply. Thus, a follow-up patch should be implemented to remove inheritance flags on objects that don't support inheritance.
(In reply to Shawn Webb from comment #14) I've submitted a review to https://reviews.freebsd.org/D15061 containing the changes from your original patch which seems to fix this.
Tag as a FreeBSD 12 issue as the change is currently partially complete in HEAD.
(In reply to Mitchell Horne from comment #15) One problem with this patch is that clear_inheritance_flags() updates the global ACE rather than making a copy. This basically means that setfacl -R can't reliably be used to recursively set inheritance flags for subdirectories. With that fixed I think the patch is reasonable. I'll take care of getting it committed and adding some regression tests.
A commit references this bug: Author: markj Date: Fri Oct 26 21:17:07 UTC 2018 New revision: 339793 URL: https://svnweb.freebsd.org/changeset/base/339793 Log: Don't set NFSv4 ACL inheritance flags on non-directories. They only make sense in the context of directory ACLs, and attempting to set them on regular files results in errors, causing a recursive setfacl invocation to abort. This is derived from patches by Shawn Webb <shawn.webb@hardenedbsd.org> and Mitchell Horne <mhorne063@gmail.com>. PR: 155163 MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D15061 Changes: head/bin/setfacl/setfacl.1 head/bin/setfacl/setfacl.c
A commit references this bug: Author: markj Date: Sat Nov 10 20:35:00 UTC 2018 New revision: 340332 URL: https://svnweb.freebsd.org/changeset/base/340332 Log: MFC r339793: Don't set NFSv4 ACL inheritance flags on non-directories. PR: 155163 Approved by: re (gjb) Changes: _U stable/12/ stable/12/bin/setfacl/setfacl.1 stable/12/bin/setfacl/setfacl.c