Re: For review: Server instrumentation patch
От | Andrew Dunstan |
---|---|
Тема | Re: For review: Server instrumentation patch |
Дата | |
Msg-id | 42E3DF9E.6070601@dunslane.net обсуждение исходный текст |
Ответ на | Re: For review: Server instrumentation patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: For review: Server instrumentation patch
|
Список | pgsql-hackers |
Tom Lane wrote: >Andreas Pflug <pgadmin@pse-consulting.de> writes: > > >>>This patch looks good. The only question I have is why you >>>didn't want the pgport rename/unlink calls? >>> >>> > > > >>Because I wanted the standard platform behaviour of both. For backend >>storage subsystem purposes, it's certainly necessary to emulate *ix >>behaviour of deleting a file in use, but for generic file access IMHO >>the generic behaviour should be exposed. >> >> > >I'm going to repeat my firm opposition to this patch. Under the >innocuous-sounding banner of "server instrumentation", you are once >again trying to put in generic file access capabilities that will allow >remote Postgres superusers full access to the server filesystem. > > > > [well stated security objections snipped] (Since we're visiting this again) It also just strikes me as just the wrong way to go about solving the apparent problem. If we want to make remote configuration or other operations possible, then instead of granting access to server resident files we should invent and implement an API that provides superusers the appropriate operations. For one thing, this would mean that if we ever decided to replace the current flat file system we use with something else we need not break clients that use the API. Just granting file access even if restricted to the data dir strikes me as a kludge. cheers andrew
В списке pgsql-hackers по дате отправления: