user roles

[David Merrill]

On Wed, Jan 03, 2001 at 09:28:46PM -0500, Derek Atkins wrote:
> David Merrill <dmerrill@lupercalia.net> writes:
> 
> > > 	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.
> 
> Hrm..  I see the problem with this approach, then.  I guess there is
> no way to define a single namespace for users and groups, huh?  Sigh.

Sigh.

In an rdbms, all your data structures are the same. Square.
Hierarchical. It is really very different from other programming. To
be good at it, you have to have an extremely organized approach and a
certain structured way of thinking. Your brain has to grok schema in
fullness.

> > > > ACL
> > > > ---
> > > > acl_guid
> > > > set of permissions
> > 
> > This is a complete set of permissions to all objects.
> 
> But that could get huge?  What if I wanted to put a different acl on
> every single Transaction?  That would be a HUGE enumeration in the
> table.  The other problem is that determining what the ACL is on a
> particular object becomes very hard, so viewing and changing the acl
> on a specific object is extremely challenging, no?

It is no larger than your scheme; the data is simply distributed
differently. Each of your acls resides in a field of a table.
Unless...

It does not provide the ability to customize access by the individual
transaction. Would your method allow us to define particular
permissions at the transaction level? That means each transaction
record would have a field for an acl (or a pointer to an acl)?

> > > 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?
> 
> Yes.  Each Transaction would reference an acl that defines the access
> for that particular transactin.

Well that is incredibly flexible and powerful.
 
> > Yes, the concept is the same. I thought so.
> 
> Then perhaps I just don't see how you do it given the data structures
> that you've defined.  It seems like you have to be able to reference
> every object in the acl table, rather than reference the acls from the
> objects.  I would think there would be much less data my way, because
> you have many fewer ACL choices than you do transactions.

I think this is cleared up now. I don't allow discrimination at the
object level.

> Also, I think it's much easier to ask an object: what is your acl?
> 
> > Sure, that would be great. I'm at 919-859-9706, but I can only talk at
> > night. My boss wouldn't appreciate it. :-)
> 
> It's a bit late tonight; could you let me know what time tomorrow I
> shoud call you?  I'm in US/Eastern, but I can call you as soon as you
> are available (after 4:30).

I'm us eastern also; I live in Raleigh, NC.

I have sometimes worked late hours the last few weeks, but I should be
home by 8:00.

I don't know what to think about your proposal now. I'm going to have
to think about it. It is far more flexible than my plan, but the
concept is so new to me I'm not sure how to go about implementing it.
If you know of a good source to learn more about acls, let me know,
please.

Thanks!

-- 
Dr. David C. Merrill                     http://www.lupercalia.net
Linux Documentation Project                dmerrill@lupercalia.net
Collection Editor & Coordinator            http://www.linuxdoc.org
                                       Finger me for my public key

>From your silence, you will sing.
>From your burdens, grow your wings.