Other than for DB administration, I don't see the point in this. :)
The argument is that Postgres' built-in authorization is better tested
than anything you can write on your own. Plus, by protecting the data
at the lowest database level, you can be sure that no Python or other
utility can bypass your security policy.
Yes. :) By enforcing it at the database level, any client connecting to
the database will need to play by the same rules, short of being a
database superuser.
The downside is that it's meant for a limited number of Postgres
users, and is not attuned to a web application that may create dozens
of users in a week. So it only works if you can map your web users
into a few pre-specified database users. You would also have to log
into the database with the highest-permission user and then switch
down using a SQL statement, similar to Unix 'su'. But I'm not sure how
you'd go up in privilege again in another request (if you're reusing
the same connection).
This is also true; Vertically Challenged requires that the database
roles being used are just that - roles that define specific actions.
Users are then stored in a table as normal, and mapped to the correct
role at session initiation via the Postgres command SET ROLE.
SET ROLE allows for the permissions change to be undone, as well, so
that a database handle can be reset to use the more permissible role at
the end of the execution session.
The other thing is it doesn't have row-based permissions, only
table-based. Unless it was added in PostgreSQL 8.4. Although I suppose
you can mimic row-based permissions in a stored procedure.
It wasn't, though column-level permissions are available.
So far, stored procedures are the only way to allow for row-level
permissions.
The other issue is how to get all your stored procedures into the
database. The solution seems to be text SQL files in your version
control system.
This is what we do, though PG9.0 is going to allow for DO blocks.
Combined with pl/pythonu, it should be possible to issue queries which
encapsulate (for example) pickled code from the Python layer.
As pl/pythonu is an untrusted language, this *will* require a database
superuser, though. :(
Regards,
--
Aurynn Shaw
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 ext 103
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
We are all in the gutter, but some of us are looking at the stars.
-- Oscar Wilde
[email protected]
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
