user roles

[David Merrill]

On Wed, Jan 03, 2001 at 09:56:36AM -0500, Derek Atkins wrote:
> David Merrill <dmerrill@lupercalia.net> writes:
> 
> > I was speaking only about the audit trail within the db itself. I
> > haven't given any thought to other auditing requirements.
> 
> Ok, so long as we don't require a specific database login for each
> registered user, I'm ok with that. ;)
> 
> > BTW, I think postgres supports Kerberos.
> 
> Hrm, I didn't know that.. You learn something new every day (hrm, this
> is a bad sign -- it's only 10am! :)

Yes, I checked, and it does support kerberos. See
http://www.postgresql.org/users-lounge/docs/7.0/postgres/c1688317027.htm

> > I want the final shipping package to be preconfigured with working,
> > configured roles. The admin will be able to change them, or completely
> 
> Agreed.
> 
> > "Does this imply that roles need ACLs too" short answer, yes. Long
> > answer, all ACLs are assigned via a role, never directly to an
> > individual. All rights are obtained via a role. This complexity can be
> > hidden from the user in a single-user system, by the client, if it
> > wants to do that, but ultimately it is a role that has rights, not a
> > user.
> 
> I'm not convinced this is the best approach.. There are times when you
> definitely want to assign ACLs based on users, not on roles.  Unless
> you are implying that you must create a new role for every
> "singly-acled user", where that role contains exactly one user..
> Seems a bit overkill to me.  It would just be easier to allow users
> (as well as roles) on ACLs.
> 
> I can certainly see the benefit of using roles on ACLs, so you can add
> someone to the role and they get full access to that role's
> capabilities on all objects in the database.  But there are times when
> you want to specifically allow (or perhaps specifically DISALLOW)
> access to particular users.  For example, I might not want my wife to
> see transactions about her birthday presents. ;) Would I need to
> create "role::wife" and put her in that?  I certainly don't ever
> expect my wife to change....

You could create a role named for your wife and use that to achieve
the effect you want. But you say this is an inconvenience, and I'm
sure you're right about that.

The client could do this for you and make it appear as if you were
assigning rights directly, while still maintaining only a single way
of actually implementing the rights.

Or, actually, the server could do this. So the system as a whole would
"allow" for rights to be assigned directly to a person, but do it
using a role named for that person. My reasoning for not wanting to
have directly assigned rights is that it results in a more complex
system, in which rights are assigned either way. More code, more risk
of bugs. The security infrastructure especially should be as simple as
possible (and no simpler).

What I *don't* want is for there to be a separate set of tables for
storing the user's rights and a set for storing the role's rights.

Does this sound like a good compromise?

-- 
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

I'm a scheming, conniving bastard who doesn't care for any hurt
feelings or lost hours of work if it just results in what I
consider to be a better system...
I can say "I don't care" with a straight face, and really mean it.
     ...Because I'm a bastard, and proud of it!
		-- Linus Torvalds