Thread: Re: Scheduler in Postgres

Tom Lane wrote:
> Christopher Browne <cbbrowne@acm.org> writes:
>> Centuries ago, Nostradamus foresaw when decibel@decibel.org ("Jim C.
>> Nasby") would write:
>>> In PostgreSQL, there's currently no way to assume the identity of
>>> another user.
>
>> I'm confused at that...
>
>> There seem to be ways at time of connection establishment, whether
>> via the psql "-U" option, or the PGconnect "dbuser=foo" option, or
>> during a psql session via "\c - newuser".
>
> Not to mention SET SESSION AUTHORIZATION.

Chris, all the options you mention require the entry of a password, or
for SET SESSION AUTHORIZATION, that the original connection was made by
a superuser (which in turn would have required entry of a password.)
It's possible to circumvent this with trust authentication, but the
PostgreSQL documentation recommends against general use of trust
authentication (and I agree with that recommendation in a production
environment.)

As described in other messages in this thread, putting a scheduler in
the database would allow authentication to be done at the time the job
is set up, and then the job to be run without reauthorization.

--
Guy Rouillier

"Guy Rouillier" <guyr@masergy.com> writes:
>> Not to mention SET SESSION AUTHORIZATION.

> Chris, all the options you mention require the entry of a password, or
> for SET SESSION AUTHORIZATION, that the original connection was made by
> a superuser (which in turn would have required entry of a password.)
> It's possible to circumvent this with trust authentication, but the
> PostgreSQL documentation recommends against general use of trust
> authentication (and I agree with that recommendation in a production
> environment.)

> As described in other messages in this thread, putting a scheduler in
> the database would allow authentication to be done at the time the job
> is set up, and then the job to be run without reauthorization.

I think this is really a content-free argument.  An outside-the-database
cron substitute would have to have superuser privileges so that it could
do SET SESSION AUTHORIZATION, but so what?  If the DBA doesn't want to
cooperate in setting up a scheduler, he probably doesn't want his users
to use an inside-the-database one either.

There aren't really any permissions or security issues here that
weren't solved long ago.  People have been using cron jobs driving
connect-as-superuser scripts to do periodic pg_dump and vacuum
maintenance since forever.  An outside-the-database scheduler for user
tasks is a straightforward increment on that.

            regards, tom lane