o Update copyright date

o Revise description in light of commits over last month including:
  - ACL editing library is now implemented
  - ACLs are now implemented

Obtained from:	TrustedBSD Project
This commit is contained in:
Robert Watson 2001-03-26 19:55:35 +00:00
parent 855fee851a
commit a21c3aa0e9
2 changed files with 62 additions and 92 deletions

View File

@ -1,5 +1,5 @@
.\"-
.\" Copyright (c) 2000 Robert N. M. Watson
.\" Copyright (c) 2000, 2001 Robert N. M. Watson
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
@ -37,37 +37,23 @@
.Fd #include <sys/types.h>
.Fd #include <sys/acl.h>
.Sh DESCRIPTION
As shipped,
.Fx 4.0
permits file systems to export
Access Control Lists via the VFS, and provides a library for userland
access to and manipulation of these ACLs, but support for ACLs is not
provided by any file systems shipped in the base operating system.
The library calls shipped with 4.0 include routines to allocate,
duplicate, retrieve, set, and validate ACLs associated with file objects.
.Fx
permits file systems to export Access Control Lists via the VFS, and
provides a library for userland access to and manipulation of these ACLs.
Not all file systems provide support for ACLs, and some may require that
ACL support be explicitely enabled by the administrator.
The library calls include routines to allocate, duplicate, retrieve, set,
and validate ACLs associated with file objects.
As well as the POSIX.1e routines, there are a number of non-portable
extensions defined that allow for alternative ACL semantics than the
POSIX.1e semantics, such as AFS, NTFS, Coda, and NWFS semantics. Where
routines are non-standard, they are suffixed with _np to indicate that
POSIX.1e semantics, such as AFS, NTFS, Coda, and NWFS semantics.
Where routines are non-standard, they are suffixed with _np to indicate that
they are not portable.
.Pp
POSIX.1e describes a set of ACL manipulation routines to manage the
contents of ACLs, as well as their relationships with files. This
manipulation library is not currently implemented in
.Fx ,
although
a third party library was under development at the time this document
was written. There is a general consensus that the POSIX.1e manipulation
routines are ambiguously defined in the specification, and don't meet the
needs of most applications. For the time being, applications may
directly manipulate the ACL structures, defined in acl.h, although the
recommended usage is to only ever handle text-form ACLs in applications,
generated and maintained using
.Fn acl_from_text
and
.Fn acl_to_text ,
passed directly to and from the management routines. In this manner,
an application can remain safely unaware of the contents of ACLs.
contents of ACLs, as well as their relationships with files; almost
all of these support routines are implemented in
.Fx .
.Pp
Available functions, sorted by behavior, include:
.Pp
@ -139,22 +125,21 @@ Documentation of the internal kernel interfaces backing these calls may
be found in
.Xr acl 9 .
The syscalls between the internal interfaces and the public library
routines may change over time, and as such are not documented. They are
not intended to be called directly without going through the library.
routines may change over time, and as such are not documented.
They are not intended to be called directly without going through the
library.
.Sh IMPLEMENTATION NOTES
.Fx Ns 's
support for POSIX.1e interfaces and features is still under
development at this time.
.Sh ENVIRONMENT
POSIX.1e assigns security labels to all objects, extending the security
functionality described in POSIX.1. These additional labels provide
fine-grained discretionary access control, fine-grained capabilities,
and labels necessary for mandatory access control. POSIX.2c describes
a set of userland utilities for manipulating these labels. These userland
utilities are not bundled with
.Fx 4.0
so as to discourage their
use in the short term.
functionality described in POSIX.1.
These additional labels provide fine-grained discretionary access control,
fine-grained capabilities, and labels necessary for mandatory access
control.
POSIX.2c describes a set of userland utilities for manipulating these
labels.
.\" .Sh FILES
.Sh SEE ALSO
.Xr acl_dup 3 ,
@ -167,17 +152,17 @@ use in the short term.
.Xr acl 9 ,
.Xr posix1e 3
.Sh STANDARDS
POSIX.1e is described in IEEE POSIX.1e draft 17. Discussion
of the draft continues on the cross-platform POSIX.1e implementation
mailing list. To join this list, see the
POSIX.1e is described in IEEE POSIX.1e draft 17.
Discussion of the draft continues on the cross-platform POSIX.1e
implementation mailing list.
To join this list, see the
.Fx
POSIX.1e implementation
page for more information.
POSIX.1e implementation page for more information.
.Sh HISTORY
POSIX.1e support was introduced in
.Fx 4.0 ,
and development continues.
.Fx 4.0 ;
.Fx 5.0
was the first version to include a complete ACL implementation based
on extended attributes.
.Sh AUTHORS
.An Robert N M Watson
.Sh BUGS
These features are not yet fully implemented.

View File

@ -1,5 +1,5 @@
.\"-
.\" Copyright (c) 2000 Robert N. M. Watson
.\" Copyright (c) 2000, 2001 Robert N. M. Watson
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
@ -37,37 +37,23 @@
.Fd #include <sys/types.h>
.Fd #include <sys/acl.h>
.Sh DESCRIPTION
As shipped,
.Fx 4.0
permits file systems to export
Access Control Lists via the VFS, and provides a library for userland
access to and manipulation of these ACLs, but support for ACLs is not
provided by any file systems shipped in the base operating system.
The library calls shipped with 4.0 include routines to allocate,
duplicate, retrieve, set, and validate ACLs associated with file objects.
.Fx
permits file systems to export Access Control Lists via the VFS, and
provides a library for userland access to and manipulation of these ACLs.
Not all file systems provide support for ACLs, and some may require that
ACL support be explicitely enabled by the administrator.
The library calls include routines to allocate, duplicate, retrieve, set,
and validate ACLs associated with file objects.
As well as the POSIX.1e routines, there are a number of non-portable
extensions defined that allow for alternative ACL semantics than the
POSIX.1e semantics, such as AFS, NTFS, Coda, and NWFS semantics. Where
routines are non-standard, they are suffixed with _np to indicate that
POSIX.1e semantics, such as AFS, NTFS, Coda, and NWFS semantics.
Where routines are non-standard, they are suffixed with _np to indicate that
they are not portable.
.Pp
POSIX.1e describes a set of ACL manipulation routines to manage the
contents of ACLs, as well as their relationships with files. This
manipulation library is not currently implemented in
.Fx ,
although
a third party library was under development at the time this document
was written. There is a general consensus that the POSIX.1e manipulation
routines are ambiguously defined in the specification, and don't meet the
needs of most applications. For the time being, applications may
directly manipulate the ACL structures, defined in acl.h, although the
recommended usage is to only ever handle text-form ACLs in applications,
generated and maintained using
.Fn acl_from_text
and
.Fn acl_to_text ,
passed directly to and from the management routines. In this manner,
an application can remain safely unaware of the contents of ACLs.
contents of ACLs, as well as their relationships with files; almost
all of these support routines are implemented in
.Fx .
.Pp
Available functions, sorted by behavior, include:
.Pp
@ -139,22 +125,21 @@ Documentation of the internal kernel interfaces backing these calls may
be found in
.Xr acl 9 .
The syscalls between the internal interfaces and the public library
routines may change over time, and as such are not documented. They are
not intended to be called directly without going through the library.
routines may change over time, and as such are not documented.
They are not intended to be called directly without going through the
library.
.Sh IMPLEMENTATION NOTES
.Fx Ns 's
support for POSIX.1e interfaces and features is still under
development at this time.
.Sh ENVIRONMENT
POSIX.1e assigns security labels to all objects, extending the security
functionality described in POSIX.1. These additional labels provide
fine-grained discretionary access control, fine-grained capabilities,
and labels necessary for mandatory access control. POSIX.2c describes
a set of userland utilities for manipulating these labels. These userland
utilities are not bundled with
.Fx 4.0
so as to discourage their
use in the short term.
functionality described in POSIX.1.
These additional labels provide fine-grained discretionary access control,
fine-grained capabilities, and labels necessary for mandatory access
control.
POSIX.2c describes a set of userland utilities for manipulating these
labels.
.\" .Sh FILES
.Sh SEE ALSO
.Xr acl_dup 3 ,
@ -167,17 +152,17 @@ use in the short term.
.Xr acl 9 ,
.Xr posix1e 3
.Sh STANDARDS
POSIX.1e is described in IEEE POSIX.1e draft 17. Discussion
of the draft continues on the cross-platform POSIX.1e implementation
mailing list. To join this list, see the
POSIX.1e is described in IEEE POSIX.1e draft 17.
Discussion of the draft continues on the cross-platform POSIX.1e
implementation mailing list.
To join this list, see the
.Fx
POSIX.1e implementation
page for more information.
POSIX.1e implementation page for more information.
.Sh HISTORY
POSIX.1e support was introduced in
.Fx 4.0 ,
and development continues.
.Fx 4.0 ;
.Fx 5.0
was the first version to include a complete ACL implementation based
on extended attributes.
.Sh AUTHORS
.An Robert N M Watson
.Sh BUGS
These features are not yet fully implemented.