ACLs and new object creation

Robert Watson rwatson at FreeBSD.org
Sat Nov 30 16:05:09 GMT 2002


POSIX.1e defined two classes of ACLs: access ACLs, and default ACLs.  This
question relates to the access ACLs on newly created objects.  My reading
of the POSIX.1e draft spec is that the umask should continue to be used
during the setting of new access ACLs on objects in order to maintain
application POLA.  However, quick glances at the Solaris and Linux ACL
implementations suggest that these two implementations do not use the
umask in the event a default ACL is defined for the parent object.  We
adopted the umask model under the assumption that this reduced POLA by
selecting the most conservative possible default protection.  However,
there appear to be strong arguments for the model where default ACLs
override the umask and simply use the ACL mask, as this would permit a
distinction between global and local policy, and provide a means for
"group projects" to manage protections in more useful ways.  That said, a
number of parts of the last POSIX.1e draft spec point at POLA as the
reason not to ignore the umask, especially in the rationale section. 

In our implementation, it is a lot easier to combine the two, it turns
out, because in BSD VFS implementations, the umask of a process is
combined with the creation mode before the mode is passed down into
per-file system code, and ACLs are implemented at the per-file system
level (with common support routines so multiple file systems can rely on
some of the same utility functions).  To remedy this, we'd have to start
passing both the mask and the creation mode into each file system so that
the defaults could be appropriately constructed.  This wouldn't be a
terrible burden, but I'd like to avoid doing that if the current semantics
are correct :-). 

Any thoughts?

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