| 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.0 |