Let me try to outline where I think our goals are for remote
administration. I will not comment on Dave's analysis of the patch
review process, but I think he has some valid points that this patch was
not treated properly.

Basically, I think everyone wants remote administration. Remote
administration requires several things:

o edit postgresql.conf
o edit pg_hba.conf
o reload the config files
o restart the server (for config variables requiring restart)
o view log files
o recycle log files
o rename/remove log files

All these items are on the TODO list already.

The idea of the patch was to give applications the full unix I/O
capabilities, allowing them to program these functions into
administration applications. I think the group generally would like a
higher-level API that allows something like:

SET GLOBAL log_statement = 'mod';

that would modify postgresql.conf and signal all backends to-read the
file, or a way to control pg_hba.conf using SQL queries.

While the Unix API works, it isn't really what we finally want for
remote administration. I thought this was discussed back in the 8.0
beta period, and was surprised to see the file I/O patch resurface, but
because no one objected to it, I moved forward to getting it into the
queue and applied. Later, others did object, some to the too-general
API, others based on security concerns.

I probably should have stated more clearly that the high-level API was
the proper approach, rather than moving forward with a patch I knew
untimately would lead to concerns. However, I try to refrain from
pre-judging a patch lest I become too unbiased toward patch submissions.
I try to be the advocate for patches, rather than cast judgement. (What
surprised me is that the concerns didn't surfaced so late.)

So, where does this leave us for 8.1? I don't think we have time to
implement many of the bulleted items listed above, and I don't think the
file API patch would pass a vote, but I will support a vote if people
want that.

I think it might be possible to do a few of the bulleted items while we
clean out the patches queue. In fact, I think the reload the config
file functionality was already in the file I/O patch, so we can easily
apply that. (It is a TODO item.)

Given the confusion about the patch, I think we can give folks some time
to work on any additional remote administration bulleted items while we
clean out the patches queue.

Does that sound like a plan?

[ FYI, I think some of the bulleted items can be done now via COPY.]

---------------------------------------------------------------------------

Dave Page wrote:
>
>
>
> > None of these functions are getting into 8.1 anyway; we should be
> > designing the long-term solution not making up short-lived hacks.
>
> So, going back to pre 8.0, we fixed them so they don't work outside of
> the data directory as requested, yet they were not included for unknown
> reasons.
>
> We revisited some weeks before prior to feature freeze, and I researched
> all issues raised and ask for clarification on what you weren't happy
> with as all I'd found in the archives was a sentence along the lines
> of "I really don't see any value in these". I found no outstanding
> issues in the archives, nor did I receive any in response to my
> questions.
>
> Having received no further objections, the patch was added to the queue.
> As soon as Bruce starts to look at it, presumably to apply it, you
> decide it's an unacceptable security problem, and say you'd be
> perfectly happy if there was a GUC to disable the potentially dangerous
> functions. This info would have been nice before feature freeze, but,
> OK, I appreciate you're busy.
>
> Magnus updates the patch because he's yet another one of us that thinks
> this is useful functionality and adds the GUC you said would make you
> happy with these functions.
>
> You then state, with no discussion at all, that they're not going into
> 8.1 anyway, despite us doing everything you have asked.
>
> I have two questions if I may:
>
> 1) Is there any point us working on any kind of enhanced API for remote
> admin in the future, or will the same treatment be given to that?
>
> 2) Do you now have sole say over what does and doesn't go into the
> project?
>
> I don't mean to be disrespectful - your hard work and skills are hugely
> appreciated by the whole community, but I know for a fact that a number
> of them, who between them have contributed thousands of hours and lines
> of code to the project (and I'm talking about the core project, never
> mind pgAdmin et al) cannot understand your apparent insistence on us
> not providing remote admin capabilities. I think we simply need
> clarification on how the project works these days.
>
> Regards, Dave
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that
> your message can get through to the mailing list cleanly
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Sat, Jul 30, 2005 at 11:39:20PM -0400, Bruce Momjian wrote:
> Let me try to outline where I think our goals are for remote
> administration. I will not comment on Dave's analysis of the patch
> review process, but I think he has some valid points that this patch was
> not treated properly.
>
> Basically, I think everyone wants remote administration. Remote
> administration requires several things:
>
> o edit postgresql.conf
> o edit pg_hba.conf
> o reload the config files
> o restart the server (for config variables requiring restart)
> o view log files
> o recycle log files
> o rename/remove log files
>
> All these items are on the TODO list already.

My security spider-sense tingles when I see the ability for a remote
attacker to not only completely override password, certificate and IP
absed authentication but also to easily remove logfiles.

So, while I can see the attraction of being able to futz with the
database security configuration through a PHP web interface running on
an unpatched Apache build somewhere out on the open internet (and
would like to be able to do so myself, sometimes) I'd really, really
like to see the ability to disable as much of this at compile time as
is convenient.

Cheers,
Steve

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Sat, Jul 30, 2005 at 09:35:16PM -0700, Steve Atkins wrote:
> On Sat, Jul 30, 2005 at 11:39:20PM -0400, Bruce Momjian wrote:
> > Let me try to outline where I think our goals are for remote
> > administration. I will not comment on Dave's analysis of the patch
> > review process, but I think he has some valid points that this patch was
> > not treated properly.
> >
> > Basically, I think everyone wants remote administration. Remote
> > administration requires several things:
> >
> > o edit postgresql.conf
> > o edit pg_hba.conf
> > o reload the config files
> > o restart the server (for config variables requiring restart)
> > o view log files
> > o recycle log files
> > o rename/remove log files
> >
> > All these items are on the TODO list already.
>
> My security spider-sense tingles when I see the ability for a remote
> attacker to not only completely override password, certificate and IP
> absed authentication but also to easily remove logfiles.

Yes, I'd trim that part to support only rename of log files, and
constrain the destination to the log directory. (I guess I don't need
to mention that all log file operations are already constrained to files
inside the log directory.)

For the "edit postgresql.conf" part I guess it would be important to
have some settings that would not be changeable via this interface.

--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"La primera ley de las demostraciones en vivo es: no trate de usar el sistema.
Escriba un guión que no toque nada para no causar daños." (Jakob Nielsen)

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Bruce Momjian wrote:

> I think the group generally would like a
> higher-level API that allows something like:
>
> SET GLOBAL log_statement = 'mod';

This is the typical Core point of view. Any function not usable from
psql can't be ok. So until psql isn't enabled to SET GLOBAL, the rest of
the world has to wait.

Please note that this configurability is not sufficient. If the server
is not running, it obviously can't work so a config tool must be able to
work on *.conf directly. This is how pgadmin already works, enabling an
config edit only mode to be included in pginstaller. I'm not inclined to
recode the wheel psql style.

Regards,
Andreas

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Bruce Momjian wrote:
> o ...
> o recycle log files
> o ...
>
> All these items are on the TODO list already.

Didn't find this on the TODO, what does it mean? Is it what
pg_logfile_rotate() does since my very first logger subprocess posts?

Regards,
Andreas




---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Andreas Pflug wrote:
> Bruce Momjian wrote:
> > o ...
> > o recycle log files
> > o ...
> >
> > All these items are on the TODO list already.
>
> Didn't find this on the TODO, what does it mean? Is it what
> pg_logfile_rotate() does since my very first logger subprocess posts?

Yes, I think so, and I will try to get that into CVS.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings