On Wed, Dec 4, 2013 at 7:57 PM, MauMau <maumau...@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-4...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
