Greg,
> In particular, one early question was whether to use wildcard patterns
> or schema names. People were saying wildcard patterns would be more
> flexible because people don't always set up their objects in different
> schemas. But if we had a mechanism someone wanted to use which
> depended on schemas they would be far more likely to choose to set up
> schemas for objects which belong in different security classes.
What I'm saying is that there are many users currently using schema for
security classes. I personally haven't ever encountered a DBA who used
role ownership of objects as a mechanism for security context. There's
nothing conceptually invalid about the latter approach, but it would be
hard for DBAs to grasp, and as a result less of them would use it.
Mainly that's because the concept of schema easily maps (even if
inaccurately) to the concept of directories, whose permissions IT staff
are used to managing. So it's more intuitive for a DBA to say "This is
sensitive data so I'm going to put it in the SENSITIVE schema" than to
say "this is sensitive data so I'm going to have the table belong to the
SENSITIVE role".
Further, it's common practice on other DBMSes to have a "database owner"
role which owns all database objects. So DBA who learn Postgres second
are going to do that.
If we were going for a theoretically pure approach, we'd actually have a
"security context" concept which would include a bundle of permissions
and each object would belong to one.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
