POSIX.1e ACLs and symbolic links

Robert Watson rwatson at FreeBSD.org
Tue Dec 24 16:12:22 GMT 2002


In the TrustedBSD implementation of ACLs, we assume that acl_get_file(),
acl_set_file(), et al, follow symbolic links when the target pathname
points at a symlink.  This is consistent with the behavior of chown(),
chmod(), and other POSIX protection related calls that act on paths.
However, many systems now also support lchown() and lchmod() to manipulate
ownership and mode on symlinks themselves: they operate normally on files,
but if they are performed on a symlink, they act on the symlink inode (if
appropriate).  We have a prototype implementation of the following
variations on the POSIX.1e calls that have the same semantics:

int     acl_delete_link_np(const char *_path_p, acl_type_t _type);
int     acl_delete_def_link_np(const char *_path_p);
acl_t   acl_get_link_np(const char *_path_p, acl_type_t _type);
int     acl_set_link_np(const char *_path_p, acl_type_t _type, acl_t _acl);
int     acl_valid_link_np(const char *_path_p, acl_type_t _type, acl_t _acl);

(As with our other non-portable calls, _np is appended.)

Likewise, we've added "-h" arguments to getfacl and setfacl to indicate
that symbolic links should not be followed.

To help support these, we've added similar calls to manipulate extended
attributes based on the existing POSIX.1e-derived APIs:

int     extattr_delete_link(const char *_path, int _attrnamespace,
            const char *_attrname);
ssize_t extattr_get_link(const char *_path, int _attrnamespace,
            const char *_attrname, void *_data, size_t _nbytes);
int     extattr_set_link(const char *_path, int _attrnamespace,
            const char *_attrname, const void *_data, size_t _nbytes);

Given OpenBSD's adoption of the ACL and extended attribute implementations
from FreeBSD, I imagine they may pick up these also.  Likewise, we'll
update our ports of extended attributes and ACLs to Darwin and Mac OS X to
support these interfaces also. 

Have any other platforms addressed this issue?  We're currently testing
these changes, and plan to commit them to the FreeBSD tree for inclusion
in FreeBSD 5.1 sometime during Q2 of next year.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Network Associates Laboratories

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