Обсуждение: 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?
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
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
"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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
--
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.