Re: [bug fix] pg_ctl fails with config-only directory

From: "MauMau" <maumau307(at)gmail(dot)com>
To: "Amit Kapila" <amit(dot)kapila16(at)gmail(dot)com>
Cc: "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [bug fix] pg_ctl fails with config-only directory
Date: 2013-12-05 13:00:41
Message-ID: F83147B4C5B54F0394A626355BBB8D08@maumau
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From: "Amit Kapila" <amit(dot)kapila16(at)gmail(dot)com>
> On Wed, Dec 4, 2013 at 7:57 PM, MauMau <maumau307(at)gmail(dot)com> wrote:
>> * Approach 1
>> When postgres starts, it removes Administrator privileges from its own
>> process. But is this possible at all? Windows security API is complex
>> and
>> provides many functions. It seems difficult to understand them. I'm
>> afraid
>> it would take a long time to figure out the solution. Is there any good
>> web
>> page to look at?
>>
>> * Approach 2
>> Do not call check_root() on Windows when -C, --describe-config,
>> or --single
>> is specified when running postgres. This would be easy, and should not
>> be
>> dangerous in terms of security because attackers cannot get into the
>> server
>> process via network.
>
> Approach-2 has been discussed previously to resolve it and it doesn't seem
> to be
> a good way to handle it. Please refer link:
> http://www.postgresql.org/message-id/1339601668-sup-4658@alvh.no-ip.org
>
> You can go through that mail chain and see if there can be a better
> solution than Approach-2.

Thanks for the info. I understand your feeling, but we need to be
practical. I believe we should not leave a bug and inconvenience by
worrying about theory too much. In addition to the config-only directory,
the DBA with admin privs will naturally want to run "postgres -C" and
"postgres --describe-config", because they are useful and so described in
the manual. I don't see any (at least big) risk in allowing
postgres -C/--describe-config to run with admin privs. In addition, recent
Windows versions help to secure the system by revoking admin privs with UAC,
don't they? Disabling UAC is not recommended.

I couldn't find a way to let postgres delete its token groups from its own
primary access token. There doesn't seem to be a reasonably clean and good
way.

So I had to choose approach 2. Please find attached the patch. This simple
and not-complex change worked well. I'd like to add this to 2014-1
commitfest this weekend unless a better approach is proposed.

Regards
MauMau

Attachment Content-Type Size
config_dir_win.patch application/octet-stream 1.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2013-12-05 13:03:51 Re: logical changeset generation v6.7
Previous Message Robert Haas 2013-12-05 12:44:27 Re: same-address mappings vs. relative pointers