user roles

[David Merrill]

On Wed, Jan 03, 2001 at 10:37:25AM -0500, Derek Atkins wrote:
> David Merrill <dmerrill@lupercalia.net> writes:
> 
> > Yes, I checked, and it does support kerberos. See
> > http://www.postgresql.org/users-lounge/docs/7.0/postgres/c1688317027.htm
> 
> Thanks
> 
> > 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.
> 
> This is adding levels of obscurity, in that what the user thinks
> they're doing isn't what they're actually doing.

I've dropped this idea. But I don't think it's adding levels of
obscurity to what they're doing. It is only obscuring the way it is
implemented. But it doesn't matter since it's dead idea, afaics.

> > 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).
> 
> Really?  I guess in my mind it's more complex when you have to
> maintain more data..  Basically, I now need to maintain an extra piece
> of information for every user in the system which is basically a
> 'role' with a single id.  So remind me why this is better than just
> using the username in the first place?

Because it is so much more manageable when you have sets of users who
all have the same permissions. Maybe that's not the situation I should
be optimizing, though.

> > 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.
> 
> I don't want that, either.  I want to have a single object that has
> the complete ACL.  For an example of where I'm coming from, have you
> ever looked at AFS?  It's a (secure) distributed file system (see
> www.openafs.org) and it maintains an ACL on each directory
> (unfortunately it doesn't do file-based acls).  Each ACL really is a
> list of ACL entries, and each entry has a name (which is either a user
> or a group) and 14 bit-flags (which are shown to the user as mnemonic
> characters), 7 of which have pre-defined meaning in the system.

Can you show me how you would store rights assigned to a specific user
in the same table in which you store group (role) rights, then?

> As an example, it's not unheard of to see an ACL that looks something
> like this:
> 
> Normal rights:
>   warlord rlidwka
>   warlord.root rlidwka
>   system:expunge ld
>   system:anyuser rl
> Negative rights:
>   warlord:enemies rlidwka

[snip]
 
> So perhaps I don't understand why you think you need to keep two
> lists, one for users and one for groups?  They are just names (or
> IDs), aren't they?  I must admit that AFS might get away with this
> because they require specific rules for naming, and by definition
> users and groups use the same internal id-namespace (users are
> positive numbers, and groups are negative numbers, IIRC).

Because the db doesn't work with names; it works with guids, and there
are referential integrity rules to think of.

Here are the table structures (simplified) I'm looking at right now:

USER
----
dbuser_guid

ROLE
----
role_guid
set of permissions

USER_ROLE
---------
dbuser_guid
role_guid

user_role, iow, assigns a role to the user. The permissions are in the
role table. Using my latest proposal, you would have a role record for
each user, created automatically when you create a user. Assigning
rights to the user specifically is a matter of changing the
permissions in this record.

See, I'm thinking at the level of the data tables, and how to
represent the permissions and roles. Presenting it in another format
to the client is easy, and a different problem. The api would have a
function for "assign this right to this user" and a different funtion
for "assign this right to this group", and so the db knows where,
specifically, to store the new rights.

And I'm not recommending separate lists for groups and users. I am in
fact proposing a way around doing that. I thought when you said to
assign permissions directly to users you intended to add the "set of
permissions" fields directly into the dbuser table. I think now I
might have misunderstood.

I'm beginning to think we're talking past each other?

> > Does this sound like a good compromise?
> 
> It sounds like more work than it needs to be, but I think we're
> getting there ;)

Yeah, we'll get there eventually.

-- 
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 am the soul of nature
That gives life to all the universe.
>From Me all things proceed
And unto Me they must return.
		-- from The Charge of the Goddess, Doreen Valiente