content-based access control (Re: views, access control, etc)
От | De Clarke |
---|---|
Тема | content-based access control (Re: views, access control, etc) |
Дата | |
Msg-id | de-980114122227.A1C433@ronin.ucolick.org обсуждение исходный текст |
Список | pgsql-hackers |
Seems like the discussion on views and access control is drifting in a direction that interests me. At the risk of once again bringing up an issue that's already been solved and tabled, I offer the following wish item: Content-based access control (CBAC). In my experience, when these words are uttered, DBAs and MIS designers groan. I wish CBAC were never required. Unfortunately sometimes it is, and I wonder if the PG team is thinking about it. Column protection is not CBAC, of course, though it sorta feels like it. Column protection can be useful, but I've had less need for it than true CBAC. I'd like to see column AC in PG someday, but it's not very important to me personally -- whereas I have immediate requirements for CBAC. In true CBAC, the whole record is confidential. In table T, User X "owns" some records and User Y "owns" some records, and the two of them should not see each other's records. You can address this problem with views (if your view mechanism allows RSE as well as FSE, and if views don't inherit AC from parent tables). But this gets you into a maintenance headache, where you're creating new views every time a new user joins the crowd. What I'd like, when I really think about it, is a rule mechanism for selects. Perhaps PG already has this, but my conceptual model is the Sybase trigger feature. On Update and Delete (but not select) in the older Sybase engines, the DB designer can interrupt the transaction and abort or alter it according to rules coded in SQL. This was *very* useful, but (at least back then) it didn't work on select. I wish that all I had to do was code the records with the owner UID, and slap a "select trigger" or rule on the table that said effectively: on a select, if record N has a user code not matching the user code of the query connection, suppress that record from the output stream. [We could get more sophisticated than that, of course: if (RSE) and (group|user code) in (list)...] Of course the privileged user (database owner or postgres) would have to be exempt. I'd like to see this suppression mechanism work for COUNT and all other stats. In fact, to each user, the table should look like it contains only that user's data. That would be truly cool. Like a view, but rule-based. I *could* write a canned UI that creates this kind of view dynamically as it starts up, but (imho) rules don't belong in the app, they belong in the engine. I want my access control to be proof against C code using API lib, interactive sql sessions, and any other way users can query the db. So, is this "already in 6.3"? Has anyone faced this problem and solved it by various other clever means? I haven't thought it through as clearly as I would like, so I'd be interested to hear from those who have. de ............................................................................. :De Clarke, Software Engineer UCO/Lick Observatory, UCSC: :Mail: de@ucolick.org | "There is no problem in computer science that cannot: :Web: www.ucolick.org | be solved by another level of indirection" --J.O. :
В списке pgsql-hackers по дате отправления: