Extending text-format ACLs
Robert Watson
rwatson at freebsd.org
Wed Apr 14 02:16:06 GMT 2004
On Tue, 13 Apr 2004, Tim Kientzle wrote:
> In doing further testing on my 'tar' implementation, I'm wondering if
> there's a way to improve the efficiency of acl_get_file.
>
> In particular, I've found that acl_get_file is the biggest malloc
> consumer I have. I'm calling acl_get_file twice for every file (for
> access and default ACLs), and each call invokes acl_init to create the
> ACL structure (which almost always gets immediately freed when I
> discover that it has only the standard entries).
>
> I know I can skip the default ACL for non-directories, which would cut
> out a lot of the heap pressure, but I would like to find a way to avoid
> calling acl_get_file unless I know I need to.
>
> Ideally, I'd like some piece of data in struct stat that I can use to
> tell whether or not there is extended ACL data for this file. (Maybe a
> read-only bit in st_flags that indicates "extended ACL exists"?)
When we first explored doing this (so as to implement '+' output in
ls(1)), I discovered that (at least on FreeBSD), there were no free bits
in the st_mode field. When we implemented UFS2 for FreeBSD, we explicitly
discussed not only using a system flag to flag the presence of extended
ACL data, but also using that to improve performance by not looking for
ACL extended attributes if the flag wasn't present, avoiding performing an
extended attribute read operation. In UFS2, we broke out system and user
flags into separate fields to increase the number of flag fields, but I'm
not sure we necessarily exposed the additional field size to userspace, so
I'm not sure whether there are easily visible bits there. In order to use
that hint in userspace usefully though, you'd need semantics that support
ls(1)'s need to display a flag for an extended access ACL, but the need
for tar to detect the presence of access or default ACLs. Which suggests
possibly two flags, one for default, and one for access.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org Senior Research Scientist, McAfee Research
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message
More information about the posix1e
mailing list