Обсуждение: Security Concerns over User 'postgres'

We are running on Red Hat Enterprise Linux 4.0, using PostgreSQL 8.1.4 .

We created our PostgreSQL instance by compiling it from source, and the instance is working just fine. User postgres runs the service; we do not know what the password is, and we think it got created automatically by the compile / install process.

However, my user community is concerned that the password for PostgreSQL (which is MD5 encrypted) could be cracked, and would like to secure it from having access to the shell. I tried attaching /sbin/nologin to the postgres user login information, but that does not work since we use /etc/init.d/postgresql to start and stop the engine.

Does anybody have any suggestions on how to properly address these concerns?

Lane M. Van Ingen

Charleston, SC

"Lane Van Ingen" <lvaningen@esncc.com> writes:
> We created our PostgreSQL instance by compiling it from source, and the
> instance is working just fine. User postgres runs the service; we do not
> know what the password is, and we think it got created automatically by the
> compile / install process.

Are you sure it even *has* a password?  In the default RPM installation,
user postgres is created without any password --- the only way to become
postgres is to su there from root, and if you've got root you hardly
need to crack into postgres.

            regards, tom lane

Hi,

Only create one user to your aplications and give to her rights to acess your database

You can change the password of postgresql user

In your linux distro type:

su - postgres

psql -U postgres

in the prompt of postgres type:

# alter user postgres with password 'your new password';

After this your password of user postgres are change.

Create an user to your aplications and give this to all users.

Don´t forget of rights (INSERT,SELECT,UPDATE,DELETE) on your tables to this user.

[],s

Marcelo Costa
DBA
Executive Secretary of Education from Pará/Amazônia/Brazil






--
Marcelo Costa

Looked at /etc/shadow, and (in fact) it doesn't have a password, so I was
wrong about that.

Tried to use the login command to login directly log into postgres, but for
some reason could not do that on RHEL 4.0 either. So, like you said, I am
not certain that I have a vulnerability here at all, other than su-ing from
root.

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Friday, September 22, 2006 3:08 PM
To: Lane Van Ingen
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Security Concerns over User 'postgres'

"Lane Van Ingen" <lvaningen@esncc.com> writes:
> We created our PostgreSQL instance by compiling it from source, and the
> instance is working just fine. User postgres runs the service; we do not
> know what the password is, and we think it got created automatically by
the
> compile / install process.

Are you sure it even *has* a password?  In the default RPM installation,
user postgres is created without any password --- the only way to become
postgres is to su there from root, and if you've got root you hardly
need to crack into postgres.

            regards, tom lane

lvaningen@esncc.com ("Lane Van Ingen") writes:
> Looked at /etc/shadow, and (in fact) it doesn't have a password, so I was
> wrong about that.
>
> Tried to use the login command to login directly log into postgres, but for
> some reason could not do that on RHEL 4.0 either. So, like you said, I am
> not certain that I have a vulnerability here at all, other than su-ing from
> root.

I'm certain; you do NOT have a vulnerability there, if there is no
password in /etc/shadow.  (Well, barring stupidity like dramatic
misconfiguration of PAM to accept logins without passwords :-).)
--
(format nil "~S@~S" "cbbrowne" "cbbrowne.com")
http://linuxdatabases.info/info/finances.html
Rules of the Evil Overlord #10.  "I will not interrogate my enemies in
the inner sanctum  -- a small hotel well outside  my borders will work
just as well." <http://www.eviloverlord.com/>

We are running PostgreSQL 8.1.4 on Red Hat Enterprise Linux 4.0 platforms
that are deployed worldwide.

In our most recent release, we started using a Java tool called IZPack to
install and start up our application, including PostgreSQL. We are finding
that we need to slow down this Java tool as it installs our application,
since it appears the tool does not wait for each step in the install script
to complete before executing the next step. This is affecting a successful
install of PostgreSQL.

QUESTION: what are the few last steps that PostgreSQL does when it starts
up? I am looking for things that I can check to be sure it has completed
installation (from a script) before allowing the script to proceed to the
next step, like:
  - opening a socket
  - creating a PID file
  - etc.

actually, wouldn't it be interesting to see a description of all the
things that go on from start to finish, in general or course.  It helps
to know the logic behind the scenes when things break; not if, when.



On Wed, Sep 27, 2006 at 10:05:24AM -0400, Lane Van Ingen wrote:
> QUESTION: what are the few last steps that PostgreSQL does when it starts
> up? I am looking for things that I can check to be sure it has completed
> installation (from a script) before allowing the script to proceed to the
> next step, like:
>   - opening a socket
>   - creating a PID file
>   - etc.

"Lane Van Ingen" <lvaningen@esncc.com> writes:
> QUESTION: what are the few last steps that PostgreSQL does when it starts
> up? I am looking for things that I can check to be sure it has completed
> installation (from a script) before allowing the script to proceed to the
> next step, like:

I'm confused about whether you are talking about installation or server
startup.  If installation, shouldn't your script just be waiting for the
subprocess to exit?  As for server startup, the best procedure is the
one pg_ctl uses: try to make a connection, if fail, sleep a second or so
and try again.

            regards, tom lane

Forgot about 'pg_ctl status'. That will work fine for my needs.

Ray Stell mentioned it would be helpful to see a description of all the
things that go on from start to finish, in general or course. I agree. It
helps to know the logic going on behind the scenes when things break. I had
a problem in August where PostgreSQL would not come up; I finally traced it
to broken links in the libraries, but it took a long time to find .... and
there were no error messages logged to help. Does this kind of information
exist anywhere?

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Wednesday, September 27, 2006 10:16 AM
To: Lane Van Ingen
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] What Are Last Steps Performed When PostgreSQL Starts?

"Lane Van Ingen" <lvaningen@esncc.com> writes:
> QUESTION: what are the few last steps that PostgreSQL does when it starts
> up? I am looking for things that I can check to be sure it has completed
> installation (from a script) before allowing the script to proceed to the
> next step, like:

I'm confused about whether you are talking about installation or server
startup.  If installation, shouldn't your script just be waiting for the
subprocess to exit?  As for server startup, the best procedure is the
one pg_ctl uses: try to make a connection, if fail, sleep a second or so
and try again.

            regards, tom lane

Lane Van Ingen wrote:
> Forgot about 'pg_ctl status'. That will work fine for my needs.
>
> Ray Stell mentioned it would be helpful to see a description of all the
> things that go on from start to finish, in general or course. I agree. It
> helps to know the logic going on behind the scenes when things break. I had
> a problem in August where PostgreSQL would not come up; I finally traced it
> to broken links in the libraries, but it took a long time to find .... and
> there were no error messages logged to help. Does this kind of information
> exist anywhere?

The information exists only in the source code.

--
  Bruce Momjian   bruce@momjian.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

On Thu, 2006-09-28 at 12:32 -0400, Bruce Momjian wrote:
> Lane Van Ingen wrote:
> > Forgot about 'pg_ctl status'. That will work fine for my needs.
> >
> > Ray Stell mentioned it would be helpful to see a description of all the
> > things that go on from start to finish, in general or course. I agree. It
> > helps to know the logic going on behind the scenes when things break. I had
> > a problem in August where PostgreSQL would not come up; I finally traced it
> > to broken links in the libraries, but it took a long time to find .... and
> > there were no error messages logged to help. Does this kind of information
> > exist anywhere?
>
> The information exists only in the source code.

I could see the merit of having that info in the docs.

Brad.