root/administartor user check option.
I would like to start a discussion about having an extra option in PG
which makes possible to bypass (or not check) whether the current user
has root/administrative privileges especially (or only) for Windows.
The following is the situation:
It would be great to be able to distribute PG as standalone database for
an standalone application within Windows. Because of the security check
within PG an extra Windows user must be created(postgres user). This is
not always possible/wanted because of the Windows (XP) user profile
settings on some operational domains. Network admins tend to lock most
of the things for normal users on Windows/XP in most companies which
disallows creating an extra user for PG and installing it as service on
Windows clients
Next to above most of the Windows users at home are local admins which
is not accepted by PG (when starting up).
In my case I need to distribute PG within the setup of a custom
standalone application. This is done very easily with MS Access, MSDE,
Firebird even with MySQL.
I was thinking of an extra startup option or perhaps a compile time
option in ./configure
Am Dienstag, 25. Juli 2006 12:01 schrieb Gevik Babakhani:
I would like to start a discussion about having an extra option in PG
which makes possible to bypass (or not check) whether the current user
has root/administrative privileges especially (or only) for Windows.
This has been shot down many times before, and the arguments you are
presenting are not new.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
This has been shot down many times before, and the arguments you are
presenting are not new.
Has there been a solution found for the arguments/issues. Is there any
history about why at some point we decided to enforce the security
option?
Gevik Babakhani wrote:
This has been shot down many times before, and the arguments you are
presenting are not new.Has there been a solution found for the arguments/issues. Is there any
history about why at some point we decided to enforce the security
option?
There is nothing new about this. It it not a Windows specific
requirement - we enforce it on all platforms and have long done so.
Removing or disabling the test without removing some of the dangerous
capabilities would be a major security hole. For example: postgres can
deliver to any authenticated user the contents of any text file on the
system that the database user can read. Do you want the responsibility
of allowing that for any file the administrator can read? No, I thought
not. Neither do we.
Running Windows services as the admin user is just lazy and incompetent.
The is no more polite word for it. And that goes for all services, not
just postgres. The fact that it is a very widespread practice does not
make it right - it does however tell you something about the level of
security consciousness among both administrators and software developers
in the Windows world. My understanding is that Microsoft now advises
against this practice.
Short answer: the solution lies in educating the lazy and incompetent
users and administrators, not in introducing dangerous insecurity into
postgres.
cheers
andrew
Gevik Babakhani <pgdev@xs4all.nl> writes:
This has been shot down many times before, and the arguments you are
presenting are not new.
Has there been a solution found for the arguments/issues. Is there any
history about why at some point we decided to enforce the security
option?
Read the list archives ...
regards, tom lane
Removing or disabling the test without removing some of the dangerous
capabilities would be a major security hole. For example: postgres can
deliver to any authenticated user the contents of any text file on the
system that the database user can read. Do you want the responsibility
of allowing that for any file the administrator can read? No, I thought
not. Neither do we.
True. This means that one just cannot "copy over" PG files and run the
database without creating additional users and services.
Just looking at how much windows standalone apps are being developed
which potentially could use an "embedded" or "light" version of PG, I
still think the option should be considered. Perhaps in a more
restricted or striped-down version of PG. (PG Light or something).
Gevik Babakhani wrote:
Removing or disabling the test without removing some of the dangerous
capabilities would be a major security hole. For example: postgres can
deliver to any authenticated user the contents of any text file on the
system that the database user can read. Do you want the responsibility
of allowing that for any file the administrator can read? No, I thought
not. Neither do we.True. This means that one just cannot "copy over" PG files and run the
database without creating additional users and services.Just looking at how much windows standalone apps are being developed
which potentially could use an "embedded" or "light" version of PG, I
still think the option should be considered. Perhaps in a more
restricted or striped-down version of PG. (PG Light or something).
Postgres is BSD, so feel free to create and "Insecure Postgres" and
distribute however you like.
Note that pg_ctl contains code to be started as admin and drop the
privileges early. That may be able to satisfy your requirements without
being extremely insecure.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Humm, perhaps it would be great learning curve for me to begin with
something to be like a "Embedded PG for Windows" or "PG Light for
Windows".......(Daydreaming now..........)
Show quoted text
On Tue, 2006-07-25 at 08:26 -0400, Alvaro Herrera wrote:
Gevik Babakhani wrote:
Removing or disabling the test without removing some of the dangerous
capabilities would be a major security hole. For example: postgres can
deliver to any authenticated user the contents of any text file on the
system that the database user can read. Do you want the responsibility
of allowing that for any file the administrator can read? No, I thought
not. Neither do we.True. This means that one just cannot "copy over" PG files and run the
database without creating additional users and services.Just looking at how much windows standalone apps are being developed
which potentially could use an "embedded" or "light" version of PG, I
still think the option should be considered. Perhaps in a more
restricted or striped-down version of PG. (PG Light or something).Postgres is BSD, so feel free to create and "Insecure Postgres" and
distribute however you like.Note that pg_ctl contains code to be started as admin and drop the
privileges early. That may be able to satisfy your requirements without
being extremely insecure.
-----Original Message-----
From: "Gevik Babakhani" <pgdev@xs4all.nl>
To: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Sent: 25/07/06 11:27
Subject: [HACKERS] root/administartor user check option.
I would like to start a discussion about having an extra option in PG
which makes possible to bypass (or not check) whether the current user
has root/administrative privileges domains.
8.2 will run under an admin account. It sheds unwanted privileges at startup.
/D
Import Notes
Resolved by subject fallback
Gevik Babakhani wrote:
Removing or disabling the test without removing some of the dangerous
capabilities would be a major security hole. For example: postgres can
deliver to any authenticated user the contents of any text file on the
system that the database user can read. Do you want the responsibility
of allowing that for any file the administrator can read? No, I thought
not. Neither do we.True. This means that one just cannot "copy over" PG files and run the
database without creating additional users and services.Just looking at how much windows standalone apps are being developed
which potentially could use an "embedded" or "light" version of PG, I
still think the option should be considered. Perhaps in a more
restricted or striped-down version of PG. (PG Light or something).
You need to start with a security audit to work out which capabilities
need to be disabled. COPY to and from files would be one obvious area,
loading user modules might be another. The point is that we have chosen
to avoid a large set of problems by forbidding running with elevated
privileges, and if you want to relax that you need to identify the
members of that set of problems, in some fairly formal way.
Frankly, if I were creating an app that needed an embedded db, I would
probably not start with postgres. Sqlite was created just for this
purpose. Ideally, for an embedded db you want to avoid the need for a
server at all, if possible. That's never going to happen with postgres.
cheers
andrew
Dave Page wrote:
-----Original Message-----
From: "Gevik Babakhani" <pgdev@xs4all.nl>
To: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Sent: 25/07/06 11:27
Subject: [HACKERS] root/administartor user check option.I would like to start a discussion about having an extra option in PG
which makes possible to bypass (or not check) whether the current user
has root/administrative privileges domains.8.2 will run under an admin account. It sheds unwanted privileges at startup.
Which user does it switch to? I was under the impression that Gevik
wanted not to have to create any extra users.Or does it abandon
privileges without switching personality (if that's possible)?
cheers
andrew
Which user does it switch to? I was under the impression that Gevik
wanted not to have to create any extra users.Or does it abandon
privileges without switching personality (if that's possible)?
Correct, With the bypass option I had in mind, I wouldn't need to create
an extra user. Just run PG under the current user.
-----Original Message-----
From: "Andrew Dunstan" <andrew@dunslane.net>
To: "Dave Page" <dpage@vale-housing.co.uk>
Cc: "Gevik Babakhani" <pgdev@xs4all.nl>; "pgsql-hackers" <pgsql-hackers@postgresql.org>
Sent: 25/07/06 17:21
Subject: Re: [HACKERS] root/administartor user check option.
Dave Page wrote:
-----Original Message-----
From: "Gevik Babakhani" <pgdev@xs4all.nl>
To: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Sent: 25/07/06 11:27
Subject: [HACKERS] root/administartor user check option.
Or does it abandon
privileges without switching personality (if that's possible)?
Yes. It drops all privileges when pg_ctl (or initdb) starts, but remains running as the original user. The OS doesn't allow those privileges to be regained.
/D
Import Notes
Resolved by subject fallback