Re: Schema security
От | Paul Lambert |
---|---|
Тема | Re: Schema security |
Дата | |
Msg-id | 4760C969.1060801@reynolds.com.au обсуждение исходный текст |
Ответ на | Re: Schema security (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Schema security
Re: Schema security |
Список | pgsql-admin |
Tom Lane wrote: > Paul Lambert <paul.lambert@reynolds.com.au> writes: >> I would have thought giving the user all privileges on a schema would by >> default add them to all objects within it, > > Why would you think that? > > The analogy to think about is that usage privilege on a schema is > comparable to read access on a directory. That doesn't necessarily give > you access to any single file in the directory --- but lack of it does > ensure you cannot get to those files. > > regards, tom lane > > Point taken and yes, I would agree that default behavior should be to not give priviledges to anything other than the explicitly defined object - but would it not be a good idea to provide some sort of cascade/recurse option to granting/revoking privileges so that doing so on a container object results in the priviledges being propogated down the line for the cases where such is desired? Taking your example of file permissions - although it is not default behavior, it is possible to recursively apply a priviledge change to a directory onto files/subdirectories within it. Certainly it can be done on OpenVMS and Windows that I work with primarily and I'm 99% sure it can be done on *ix systems too. I.e. GRANT ALL ON SCHEMA <blah> TO <role> CASCADE; NOTICE: GRANT ALL cascades to table "billings" NOTICE: GRANT ALL cascades to table "customers" NOTICE: GRANT ALL cascades to function "calculate_daily_balance()" etc... Much the same way that truncate or drop and so forth can have a cascade option to propogate down to dependant objects. -- Paul Lambert Database Administrator AutoLedgers
В списке pgsql-admin по дате отправления: