Hi William, You might want to look into the way Windows has solved it. I haven't seen any detailed docs on this beyond Keith Brown's Programming Windows Security [1], but I'm sure they're out there.
Basically, if I recall correctly, Win32 makes so that each object type can have its own set of permissions. These can be mapped into generic permissions, i.e. GENERIC_READ maps to FILE_READ for files and REGKEY_READ (or whatever it's called) for registry keys. So, the generic permissions can be used by clients to require Read, without knowing the specific bits for the object type in question. Depending on whether you want to support inheritance and grouping/containment, this can become tricky. If you want to stick with static types, maybe you should throw in an execute bit as well, it's not appropriate for all object types, but files might be one example, and you can easily define custom types that are actions rather than objects. Hope that helps, Kim [1] http://www.amazon.com/o/ASIN/0201604426 P.S. Kenneth, any chance you could set the Reply-To header to [EMAIL PROTECTED] instead of the original sender? My first stab at a reply to this thread went to Brian A. Shea... Cheers! [Ed. Thanks for the suggestion. Do others on the list want a reply-to pointing back at SC-L as well? Let me know, and I'll go with what the group wants. KRvW] > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of William Herrera > Sent: den 26 februari 2004 09:20 > To: [EMAIL PROTECTED] > Subject: [SC-L] ACL (access control lists) generic design questions > > Hello folks, > > I think some here might have suggestions about improvements > to existing ACL's. > > I'm working on an extensible access-control-list style authorization > system, beyond the usual read/write authorization schemes, > probably to be > written as a Perl module for CGI use and using a database on > the back end. > This is designed to allow fine control over the use of data and other > objects by a given user. Right now it mainly uses > read/append/edit/delete > modes, since in its present alpha form it has a well defined > groupware use, > but I intend to make it more flexible than that, generic > enough to be used > as a general-purpose open source perl object authorization module. > > In doing so, I'd like to define modes of access beyond the > ones allowed by > Unix and Windows ACL's. These, so far, include: > > list object (see the object in a ls or dir listing) > > read or view object > > append (simple data) to object > > add link (to another object) within the object > > edit (change existing object's data or structure) > > delete object > > undelete or roll back object to a prior state > > administer (change object's authorizations or modes) > > ownership (to be the creator of the object or equivalent) > > Does anyone know of an access control type they've wanted in an access > control list but not had?
