Horton

Thread

Commits

  1. Lower privilege level of programs calling regression_main

  1. lowering pg_regress privileges on Windows

    Andrew Dunstan <andrew.dunstan@2ndquadrant.com> — 2018-10-18T12:31:11Z

     From the "scratch a long running itch" department.


The attached ridiculously tiny patch solves the problem whereby while we 
can run Postgres on Windows safely from an Administrator account, we 
can't run run the regression tests from the same account, since it fails 
on the tablespace test, the tablespace directory having been set up 
without first having lowered privileges. The solution is to lower 
pg_regress' privileges in the same way that we do with other binaries. 
This is useful in setups like Appveyor where running under any other 
account is ... difficult. For the cfbot Thomas has had to make the 
script hack the schedule file to omit the tablespace test. This would 
make that redundant.


I propose to backpatch this. It's close enough to a bug and the risk is 
almost infinitely small.


cheers


andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  2. Re: lowering pg_regress privileges on Windows

    Michael Paquier <michael@paquier.xyz> — 2018-10-19T00:13:41Z

    On Thu, Oct 18, 2018 at 08:31:11AM -0400, Andrew Dunstan wrote:
> The attached ridiculously tiny patch solves the problem whereby while we can
> run Postgres on Windows safely from an Administrator account, we can't run
> run the regression tests from the same account, since it fails on the
> tablespace test, the tablespace directory having been set up without first
> having lowered privileges. The solution is to lower pg_regress' privileges
> in the same way that we do with other binaries. This is useful in setups
> like Appveyor where running under any other account is ... difficult. For
> the cfbot Thomas has had to make the script hack the schedule file to omit
> the tablespace test. This would make that redundant.
> 
> I propose to backpatch this. It's close enough to a bug and the risk is
> almost infinitely small.

+1.  get_restricted_token() refactoring has been done down to
REL9_5_STABLE.  With 9.4 and older you would need to copy again this
full routine into pg_regress.c, which is in my opinion not worth
worrying about.
--
Michael

  3. Re: lowering pg_regress privileges on Windows

    Thomas Munro <thomas.munro@enterprisedb.com> — 2018-10-19T00:25:58Z

    On Fri, Oct 19, 2018 at 1:13 PM Michael Paquier <michael@paquier.xyz> wrote:
> On Thu, Oct 18, 2018 at 08:31:11AM -0400, Andrew Dunstan wrote:
> > The attached ridiculously tiny patch solves the problem whereby while we can
> > run Postgres on Windows safely from an Administrator account, we can't run
> > run the regression tests from the same account, since it fails on the
> > tablespace test, the tablespace directory having been set up without first
> > having lowered privileges. The solution is to lower pg_regress' privileges
> > in the same way that we do with other binaries. This is useful in setups
> > like Appveyor where running under any other account is ... difficult. For
> > the cfbot Thomas has had to make the script hack the schedule file to omit
> > the tablespace test. This would make that redundant.
> >
> > I propose to backpatch this. It's close enough to a bug and the risk is
> > almost infinitely small.
>
> +1.  get_restricted_token() refactoring has been done down to
> REL9_5_STABLE.  With 9.4 and older you would need to copy again this
> full routine into pg_regress.c, which is in my opinion not worth
> worrying about.

FWIW here is a successful Appveyor build including the full test
schedule (CI patch attached in case anyone is interested).  Woohoo!
Thanks for figuring that out Andrew.  I will be very happy to remove
that wart from my workflows.

https://ci.appveyor.com/project/macdice/postgres/builds/19626669

--
Thomas Munro
http://www.enterprisedb.com

  4. Re: lowering pg_regress privileges on Windows

    Andrew Dunstan <andrew.dunstan@2ndquadrant.com> — 2018-10-19T14:00:43Z

    
On 10/18/2018 08:25 PM, Thomas Munro wrote:
> On Fri, Oct 19, 2018 at 1:13 PM Michael Paquier <michael@paquier.xyz> wrote:
>> On Thu, Oct 18, 2018 at 08:31:11AM -0400, Andrew Dunstan wrote:
>>> The attached ridiculously tiny patch solves the problem whereby while we can
>>> run Postgres on Windows safely from an Administrator account, we can't run
>>> run the regression tests from the same account, since it fails on the
>>> tablespace test, the tablespace directory having been set up without first
>>> having lowered privileges. The solution is to lower pg_regress' privileges
>>> in the same way that we do with other binaries. This is useful in setups
>>> like Appveyor where running under any other account is ... difficult. For
>>> the cfbot Thomas has had to make the script hack the schedule file to omit
>>> the tablespace test. This would make that redundant.
>>>
>>> I propose to backpatch this. It's close enough to a bug and the risk is
>>> almost infinitely small.
>> +1.  get_restricted_token() refactoring has been done down to
>> REL9_5_STABLE.  With 9.4 and older you would need to copy again this
>> full routine into pg_regress.c, which is in my opinion not worth
>> worrying about.
> FWIW here is a successful Appveyor build including the full test
> schedule (CI patch attached in case anyone is interested).  Woohoo!
> Thanks for figuring that out Andrew.  I will be very happy to remove
> that wart from my workflows.
>
> https://ci.appveyor.com/project/macdice/postgres/builds/19626669
>

Excellent. I'll apply back to 9.5 as Michael suggests.

Having got past that hurdle I encountered another one in the same area. 
pg_upgrade gives up its privileges and is then unable to write things 
like log files and analyze scripts.

The attached patch cures the problem, but it doesn't seem like the best 
cure. Maybe there is a more secure way to do it. Essentially it saves 
out the ACLS for the current directory and its subdirectories and then 
allows everyone to write to them, right before running pg_upgrade. When 
pg_upgrade is done it restores the saved ACLs.

Maybe someone who understands more about how this all works can suggest 
a less blunt force approach.

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services