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 |
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 |