On Wed, Dec 4, 2013 at 7:57 PM, MauMau <maumau307@gmail.com> wrote:
> Hello,
>
> I've found a bug and would like to fix it, but I cannot figure out how to do
> that well. Could you give me any advice? I encountered this on PG 9.2, but
> it will probably exist in later versions.
>
> [Problem]
> On Windows, a user with Administrator privileges can start the database
> server. However, when he uses config-only directory, the database server
> cannot be started. "pg_ctl start" fails with the following messages:
>
> Execution of PostgreSQL by a user with administrative permissions is not
> permitted.
> The server must be started under an unprivileged user ID to prevent
> possible system security compromises. See the documentation for
> more information on how to properly start the server.
>
>
> [Cause]
> pg_ctl runs "postgres -C data_directory" to know the data directory. But
> postgres cannot be run by a user with Administrator privileges, and displays
> the above messages.
>
>
> [Fix]
> It is ideal that users with administrative privileges can start postgres,
> with the Administrator privileges removed.
>
> Currently, initdb and pg_ctl take trouble to invoke postgres in a process
> with restricted privileges. I understand this improvement was done in 8.2
> or 8.3 for convenience. The same convenience should be available when
> running postgres directly, at least "postgres -C", "postgres
> --describe-config", and "postgres --single".
>
> Then, how can we do this? Which approach should we take?
>
> * 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.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com