Re: For review: Server instrumentation patch
От | Dave Page |
---|---|
Тема | Re: For review: Server instrumentation patch |
Дата | |
Msg-id | E7F85A1B5FF8D44C8A1AF6885BC9A0E4AC94DC@ratbert.vale-housing.co.uk обсуждение исходный текст |
Ответ на | For review: Server instrumentation patch ("Dave Page" <dpage@vale-housing.co.uk>) |
Список | pgsql-hackers |
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 25 July 2005 15:18 > To: Magnus Hagander > Cc: Andrew Dunstan; Andreas Pflug; Bruce Momjian; Dave Page; > PostgreSQL-development > Subject: Re: [HACKERS] For review: Server instrumentation patch > > > Or what about a parameter to restrict both COPY and the utility > > functions to certain subdirs only? (BTW, I was under the > impression that > > the admin functions were restricted to the pgdata directory > already, but > > I could be wrong - I don't have the latest version of the > patch around) It does. Prior to feature freeze, that was the *only* concern raised with the patch, despite significant discssion. > We've gone back and forth on that with respect to the proposed admin > functions, and I forget which way the current patch is. But > it doesn't > do much to stop the privilege escalation risk: if you can > write into any > of the same directories you can LOAD from, the risk exists. (And > detecting whether two paths overlap is very hard in general, > considering > directory symlinks, AFS mounts, etc, so we probably couldn't hope to > forbid LOADing from any writable directory.) I'm not going to repeat all the other arguments here because they've been put forward perfectly well by others, but I feel I must point out my dismay at what seems like a complete disregard for non-core applications that has been expressed to me off-list by a number of people. This patch has been discussed on and off since before 8.0 was released, and some time prior to feature freeze I took over the task of trying to get it accepted from Andreas so he could continue with other work. The patch was discussed in great depth again (prior to feature freeze) and none of these concerns were raised. Had they been, we might have worked to find an alternative solution to the problem to allow PostgreSQL to boast simple features offered by every other modern DBMS I've used. Instead, because we are so far past feature freeze, there is no chance that an altenative solution will be accepted. The common belief in the messages I've received seems to be that users that prefer to use a GUI are simply not welcome. True or not (and I do hope that is not the case), it's a great shame that it seems that PostgreSQL will remain configurable only from the command line - as one well respected member of the community wrote to me: "I hope no other open source DBMS guys are following this thead. They must be ROFL seeing how Core is trying to prevent remote administrability." Regards, Dave.
В списке pgsql-hackers по дате отправления: