Date: Tue, 7 Dec 1999 11:23:24 +0100 (MET) From: Olaf Wagner <wagner@luthien.in-berlin.de> To: freebsd-arch@freebsd.org Cc: Robert Watson <robert+freebsd@cyrus.watson.org> Subject: Re: ACL support: semantics vs. syntax in the context of multiple types of ACLs over multiple file systems in the VFS Message-ID: <199912071023.LAA28173@luthien.iceflower.in-berlin.de> In-Reply-To: <Pine.BSF.3.96.991205152156.6435A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <Pine.BSF.3.96.991205152156.6435A-100000@fledge.watson.org> you wrote: > This suggests a model wherein the operations exposed to the VFS (i.e., > vop_getacl and vop_setacl) require a specific syntax, but leave the > specific semantics to whatever layer of the file system stack receives the > request. For example, FFS might choose to map ACL operations onto > standard attributes/permissions, and only allow ACLs that fit the possible > permissions in FFS. AFS might choose to interpret the id's in question as > viceids, and the permission mask as AFS permissions. An ACLfs extension > to FFS might choose the POSIX.1e semantics. This would leave it up to the > calling program to choose the correct type of ACL when setting it for a > file or directory, and the requested ACL would be rejected if it didn't > match. This leaves opportunities for a number of problems, including > confusion by the user, application of an ACL designed for one set of > semantics on another set of semantics, etc. Also, it means that some of > the POSIX.1e ACL calls (such as acl_valid()) now depend on the target, not > just on the ACL itself as a data structure, introducing a lot of > complexity. [...] > That said, this may be the only way to go. The vast majority of UNIX > operating systems have selected either direct POSIX.1e ACL syntax + > semantics, or closely related semantics/syntax, including Solaris, IRIX, > HPUX, and Linux. But given the complexity of POSIX.1e ACL behavior, and > the desire to support other ACL models (such as the intuitive and powerful > AFS/Coda model), we would also rather not define a mechanism useful for > only one set of semantics. [...] > As such, I'm suggesting moving from just vop_getacl and vop_setacl VOPs, > to: > VOP_ACLVALID(vp, acl, type) > VOP_GETACL(vp, acl, type) > VOP_SETACL(vp, acl, type) > Currently POSIX.1e defines an ACL entry as being made up of three parts -- > an id, id qualifier, and permission set. The id identifies a principal, > the qualifier, the namespace for the principal, and the permission set is > the mask of rights. POSIX.1e defines several qualifier types, including > ACL_USER_OBJ, ACL_USER, ACL_GROUP_OBJ, ACL_GROUP, ACL_OTHER, and ACL_MASK. > I believe expanding this namespace is sufficient to take into account > differing semantics, although I'm not sure. For example, we could add an > ACL_AFS_ID to indicate that the ACL applied to an AFS viceid. Presumably > AFS vnodes would reject ACLs with qualifiers other than this, and POSIX.1e > file systems would reject AFS entries. Another alternative would be to > introduce additional ACL types, but I think that is not intuitive, as the > types are currently "access" and "default", and "access" has the same > semantics in both POSIX.1e and AFS. The standard object oriented solution for the problem you describe would be to define an ACL as an `abstract type' or an `interface', and to rely on specialized implementations of some well-defined functions for everything that is different between different types of ACLs. Now of course C is no object oriented language, but can nonetheless be used to implement object oriented concepts (the vnode fs layer is an example). The crucial point is of course the definition of the `common' interface (including the semantics) of all ACL types. As I don't really know the POSIX standard for ACLs I can of course not be sure if it is flexible enough to allow for the mentioned kind of object oriented implementation, but I would give it at least a try. In your place I would try to define a specification for all concrete types of ACL you can now imagine, considering that you are implementing abstract data types where all methods handling the data need to be contained in one module. All methods of the module (except the generation method (e.g. new_afs_acl)) would of course get a pointer to an appropriate type of ACL object as their first parameter. Then abstract the common parts into one generic ACL module, and leave the different implementations as virtual functions, that are called via a jump table. The abstract definition of a generic ACL must of course include a pointer to such a jump table, i.e. a reference to the concrete implementations of virtual methods. If you want to make the representation of an ACL public, you can do so by defining the generic part as a structure in the generic module, and extending the structure for every concrete implementation. All generation methods of ACL modules will return an extended, concrete representation of an ACL. In this way you can keep all the ACL specific stuff in one module (that can be loaded on demand) and refer all operations that need knowledge of the specific parts to the correct module (by use of abstract interfaces). To make your implementation more robust, you can also add magic numbers or type ids to all ACL objects, and implement appropriate checks at the start of every operation. I know it's a lot of work to realize an oo design in C, but at certain places the efforts are worth it and rewarded with a flexible and extensible system. I hope I haven't bored you with things that were clear to you from the beginning and not what you were really asking for, but the solution seemed so obvious and classical to me that I couldn't resist. -- /\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ || Olaf Wagner | wagner@luthien.in-berlin.de (private) | || Cranachstrasse 7 | wagner@elego.de (business) | || D-12157 Berlin | phone: +49 30 85 60 26 70 | || Germany / Deutschland | fax: +49 30 85 60 26 71 | \///////////////////////////////////////////////////////////////// To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912071023.LAA28173>