| ACL_VALID(3) | Library Functions Manual | ACL_VALID(3) |
acl_valid, acl_valid_fd_np,
acl_valid_file_np,
acl_valid_link_np —
#include <sys/types.h>
#include <sys/acl.h>
int
acl_valid(acl_t
acl);
int
acl_valid_fd_np(int
fd, acl_type_t
type, acl_t
acl);
int
acl_valid_file_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);
acl_valid(), checks this validity only with POSIX.1e
ACL semantics, and irrespective of the context in which the ACL is to be used.
The non-portable forms, acl_valid_fd_np(),
acl_valid_file_np(), and
acl_valid_link_np() allow an ACL to be checked in the
context of a specific acl type, type, and file system
object. In environments where additional ACL types are supported than just
POSIX.1e, this makes more sense. Whereas
acl_valid_file_np() will follow the symlink if the
specified path is to a symlink, acl_valid_link_np()
will not.
For POSIX.1e semantics, the checks include:
ACL_USER_OBJ,
ACL_GROUP_OBJ, and
ACL_OTHER) shall exist exactly once in the ACL. If
the ACL contains any ACL_USER,
ACL_GROUP, or any other implementation-defined
entries in the file group class then one ACL_MASK
entry shall also be required. The ACL shall contain at most one
ACL_MASK entry.The POSIX.1e acl_valid() function may
reorder the ACL for the purposes of verification; the non-portable
validation functions will not.
EACCES]EBADF]EINVAL]One or more of the required ACL entries is not present in acl.
The ACL contains entries that are not unique.
The file system rejects the ACL based on fs-specific semantics issues.
ENAMETOOLONG]ENOENT]ENOMEM]EOPNOTSUPP]| December 29, 2002 | NetBSD 10.1 |