setfacl Recursive Functionality
lattera at gmail.com
Thu Feb 10 16:36:37 UTC 2011
Attached is a new patch using the acl(3) API for removing invalid
inheritance. Unless there are other suggestions, I'll likely submit this
upstream. I didn't implement the -P flag since that's the default behavior.
On Wed, Feb 9, 2011 at 2:10 PM, Shawn Webb <lattera at gmail.com> wrote:
> Included in the attached patch is the refactor using fts(3) and with the -L
> and -H options. I'm still looking for feedback and suggestions on how to
> improve the patch. I'll also port these changes over to my getfacl patch.
> If anyone's interested in following up-to-date development of the patch,
> the link to it on github is
> I'd like to take the time to address why I created the
> remove_invalid_inherit function since I got a private email asking why it
> existed. Other than symbolic links, non-directory entries cannot have
> inheritance set. That function prevents attempting to set inheritance flags
> on non-directory entries when doing a recursive call. That way, you can run
> `setfacl -R -m user:<user>:read_data:file_inherit/dir_inherit:allow
> <directory>` and not run into errors.
> On Tue, Feb 8, 2011 at 7:51 PM, Shawn Webb <lattera at gmail.com> wrote:
>> On Tue, Feb 8, 2011 at 7:35 PM, Tim Kientzle <tim at kientzle.com> wrote:
>>> On Feb 8, 2011, at 9:58 AM, Shawn Webb wrote:
>>> > I've just finished a patch to add recursive functionality to setfacl.
>>> > I officially submit it, I'd like a few suggestions on how to improve
>>> > patch.
>>> > The part I'm worried about involves the #define directive at top. I'm
>>> > sure what ramifications using that define might have. I needed it for
>>> > remove_invalid_inherit() function to work.
>>> You should certainly not need
>>> #define _ACL_PRIVATE
>>> for any user-space utilities. What exactly is the
>>> problem without that?
>>> Your approach to directory walking here
>>> is a little simplistic. In particular, you're storing
>>> every filename for the entire tree in memory,
>>> which is a problem for large filesystems.
>>> It would be much better to refactor the code so that
>>> the actual ACL update was in a function and then
>>> recurse_directory should call that function for
>>> each filename as it visited it. That will reduce
>>> the memory requirements significantly.
>>> You should also take a look at fts(3). In particular,
>>> you'll want to implement the BSD-standard
>>> -L/-P/-H options, and fts(3) makes that much easier.
>>> (-L always follows symlinks, -P never follows symlinks,
>>> -H follows symlinks on the command line).
>> Great suggestions. I'll definitely look at implementing that
>> As a side note, it looks like my setfacl patch segfaults on
>> freebsd-current r218075 with the zpool v28 patchset applied. I wrote it on
>> freebsd 8.2-RC3 with zpool v15.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5124 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20110210/a948df2c/setfacl_recursive.obj
More information about the freebsd-current