Re: [bug fix] pg_ctl fails with config-only directory
От | MauMau |
---|---|
Тема | Re: [bug fix] pg_ctl fails with config-only directory |
Дата | |
Msg-id | F83147B4C5B54F0394A626355BBB8D08@maumau обсуждение исходный текст |
Ответ на | Re: [bug fix] pg_ctl fails with config-only directory (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [bug fix] pg_ctl fails with config-only directory
Re: [bug fix] pg_ctl fails with config-only directory |
Список | pgsql-hackers |
From: "Amit Kapila" <amit.kapila16@gmail.com> > On Wed, Dec 4, 2013 at 7:57 PM, MauMau <maumau307@gmail.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
Вложения
В списке pgsql-hackers по дате отправления: