user roles

[Derek Atkins]

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.

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

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

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

So, what does this mean?  It means that the users 'warlord' and
'warlord.root' have all 7 rights (Read, List, Insert, Delete, Write,
locK, Admin).  The group 'system:expunge' has List and Delete privs,
and the group 'system:anyuser' has List and Read privs.  This also
maintains negative rights, so anyone in the group 'warlord:warlord'
has no access, even if they are members of another group.

This is a single ACL object, but it contains both users and groups.
So by example it is possible to have single objects.  You can then go
back to the database and see who is a member of those groups
(system:anyuser happens to be a "special" group, and means "anybody,
with or without authentication".  There are a few other "special"
groups).

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

> Does this sound like a good compromise?

It sounds like more work than it needs to be, but I think we're
getting there ;)

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available