Re: GRANT ON ALL IN schema
От | Josh Berkus |
---|---|
Тема | Re: GRANT ON ALL IN schema |
Дата | |
Msg-id | 4A79D60D.1090900@agliodbs.com обсуждение исходный текст |
Ответ на | Re: GRANT ON ALL IN schema (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: GRANT ON ALL IN schema
|
Список | pgsql-hackers |
Tom, > I took a quick look at this version of the patch. Other than the > already-mentioned question of whether we really want to create a > distinction between tables and views in GRANT, there's not that > much there to criticize. It's pretty common to have a database where there are some users who have permissions on views but not on the base tables. So that would be an argument for separating the two. On the other hand, it's not a very persuasive argument; in general, such databases have complex enough security rules that GRANT ALL ON is too simple for them. So, overall, I'd tend to say that we're better off including views and tables in the same GRANT ALL. The purpose of this is to be a simple approach for simple cases, no? > I do have a feeling that the implementation > is a bit too narrowly focused on the "stuff IN SCHEMA foo" case; > if we were ever to add other filtering options it seems like we'd > have to rip all this code out and start over. But I don't have any > immediate ideas on what it should look like instead. Well, schemas do make a good grouping set for objects of different security contexts; they are certainly more reliable than name fragments (as would be supported by a regex scheme). The main defect of schemas is the well-documented issues with managing search_path. > Other than that I don't have much to say. I wonder though if this > approach isn't sort of a dead-end, and we should instead look at > making it easier to build sql or plpgsql functions for doing bulk > grants with arbitrary selection conditions. Right now we have a situation where most web developers aren't using ROLEs *at all* because they are too complex for them to bother with. I literally couldn't count the number of production applications I've run across which connect to Postgres as the superuser. We need a dead-simple approach for the entry-level DB users, and I haven't heard one which is simpler or more approachable than the GRANT ALL + SET DEFAULT approach. With that approach, setting up a 3-role, table only database to have the right security is only 6 statements. I agree that we should also provide examples of how to do this by script in the docs, and maybe even some tools on pgFoundry. But those cover the sophisticated users. For the simple users, we need a dead-simple tool. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com
В списке pgsql-hackers по дате отправления: