On Wed, Jan 03, 2001 at 06:39:29PM -0500, Derek Atkins wrote:
> David Merrill <[EMAIL PROTECTED]> writes:
>
> [snip]
>
> > Ahhh. Pseudo-code is so much more precise than English can ever hope
> > to be. Thank you. I see now that you are including an additional level
> > of abstraction, by separating "group" from "role". My concept of
> > "role" is analagous to AclEntry, and I don't have a separate "group"
> > concept.
>
> The only thing I forgot to mention was that different object contain
> acls:
>
> Account ::= {
> ...
> Acl acl
> }
>
> Transaction ::= {
> ...
> Acl acl
> }
Oh, so that's what you meant when you said the objects define the acl.
> > > Could you please explain what "referential integrity rules" there are
> > > and how they apply?
> >
> > In your IDL, you have a GUID that can be *either* a user's GUID or a
> > group's GUID. Referential integrity can't say that it can be either
> > one or the other; it must be exactly one of them. But we can just do
> > away with the refint on that field and there is no problem.
>
> Um, ok. Basically, what I was trying to get at is the equivalent of
> a union... Perhaps someting like:
>
> enum {USER, GROUP}
> GUID userID
> GUID groupID
>
> The point being a means to have (one of) either group or userid in a
> single table row.
Unfortunately, that is not supported by most rdbms. I think Oracle
will support it by defining refint to a UNION query, but that doesn't
help us.
> > Here are table structures that implement your acl concept:
> >
> >
> > USER
> > ----
> > dbuser_guid
> >
> >
> > GROUP
> > -----
> > group_guid
> >
> >
> > USER_GROUP
> > ----------
> > dbuser_guid
> > group_guid
>
> This is a mapping of users into groups, right? You use this table to
> add users to groups:
>
> group_guid dbuser_guid
> 1 warlord
> 1 linas
> 1 dlb
> 2 warlord
> 2 dmerrill
Yes, exactly.
> > ACL
> > ---
> > acl_guid
> > set of permissions
This is a complete set of permissions to all objects.
> > USER_ROLE
> > ---------
> > guid (either user or group)
> > acl_guid
>
> So, it looks like you've split what I called an AclEntry into two
> parts. You can map a set of users and groups to a set of permissions.
> However you still don't have what I called an Acl, which is a list of
> AclEntries. I'd like to assign a different set of permissions to a
> set of users/groups when they try to access a particular object. For
> example, I might want to represent this set of permissions in a single
> ACL:
>
> warlord Read, Write, Admin
> dmerril Read, Write
> groupX Read
Ahah! That is a big concept that I was lacking. An acl is specific to
an object. I conceptualized it as containing settings for all objects.
That's why there is no AclEntry in my layout.
> Then in the Transaction, Account, Split, or whatever, you reference an
> Acl. E.g., I'd reference the above ACL from the account
> "Account::Payable".
Do you mean that within the transaction table itself would be a
reference to an acl?
> > user_role is where the fun stuff happens. You have defined your users;
> > you have defined roles/acls which specify a set of permissions; you
> > have assigned each of your users to a group or groups. Then, in a
> > completely separate structure, you can assign any set of acls to a
> > user or to a group. And a user inherits all the permissions assigned
> > via the acls which have been given to him or to his groups.
>
> I think I follow you so far. I can see how you can define AclEntries:
> I can define a set of users or groups which all have the same set of
> permissions. I think we need one more table that allows us to combine
> sets of what you call USER_ROLES into a single ACL that can be
> referenced by Transactions, Accounts, splits, etc.:
>
> ACL
> ---
> acl_guid
> acl_number
What is the benefit of having separate acls for each object, rather
than just one acl that includes fields for all objects? Perhaps this
is not what the whole concept of an acl *is*, but I've never seen it
done that way.
I've snipped most of the rest of the message because now that I've
understood this important point it all makes sense.
I now am pretty strongly convinced that we *are* talking about pretty
much the same idea, although my data structures are somewhat
different. The approach I'm using is a time-honored one in database
security design, and it works well. The same functionality is of
necessity implemented differently in a database.
It might be productive for us to talk in terms of the functionality
rather than the data structures. As you do below...
> So you just need to present the model this way:
> 1) You have a set of users
> 2) You can create groups and assign user(s) to group(s)
> 3) You have an object (e.g. a specific Account) to protect
> 4) You want to assign permissions on that specific Account
> 5) You build an acl for the Account where you enumerate:
> a) each user or group that needs access to the Account
> b) what specific types of access each user or group needs
>
> There you go, you've just defined your ACL for that Account. :) Now
> repeat the process for every object.
Yes, the concept is the same. I thought so.
> > It is difficult to discuss this whole issue when we are coming from
> > such different backgrounds and seeing things through different
> > filters.
>
> Perhaps we should phone each other to discuss this? I think it might
> be a higher-throughput discussion, and we can hopefully get beyond (or
> explain) our different viewpoints. ;)
Sure, that would be great. I'm at 919-859-9706, but I can only talk at
night. My boss wouldn't appreciate it. :-)
--
Dr. David C. Merrill http://www.lupercalia.net
Linux Documentation Project [EMAIL PROTECTED]
Collection Editor & Coordinator http://www.linuxdoc.org
Finger me for my public key
The great sea has set me in motion.
Set me adrift,
And I move as a weed in the river.
The arch of sky
And mightiness of storms
Encompasses me,
And I am left
Trembling with joy.
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
