Обсуждение: pg_pwd
Hi, what is the funcionality of the file pg_pwd in $PG_DATA ? (no, there is _nothing_ in the docs) and why is world =writable & readable= ? (hey, everybody, wanna know my passwd ?) Sergio
"Sergio A. Kessler" <ser@perio.unlp.edu.ar> writes:
> what is the funcionality of the file pg_pwd in $PG_DATA ?
> (no, there is _nothing_ in the docs)
That's cause you don't need to know ;-)
Seriously, it's a flat-file copy of pg_shadow, used by the postmaster
to do password verification. (The postmaster can't look directly at
pg_shadow because it cannot participate in database operations.)
See doc/TODO.detail/pg_shadow.
> and why is world =writable & readable= ?
> (hey, everybody, wanna know my passwd ?)
It's not really a security hole because it lives inside a directory
that's mode 700 (unless you tampered with the default permissions
setup). However, I agree it oughta be changed anyway.
The real issue here is that backend-side COPY writes files with mode
666, which seems a strange and dangerous choice to me. But someone once
thought it was a good idea, because COPY goes out of its way to make
that happen. Does anyone have a clue why?
regards, tom lane
Tom Lane wrote: > > "Sergio A. Kessler" <ser@perio.unlp.edu.ar> writes: > > what is the funcionality of the file pg_pwd in $PG_DATA ? > > (no, there is _nothing_ in the docs) > > That's cause you don't need to know ;-) > > Seriously, it's a flat-file copy of pg_shadow, used by the postmaster > to do password verification. (The postmaster can't look directly at > pg_shadow because it cannot participate in database operations.) > See doc/TODO.detail/pg_shadow. where ? can you post an absolute url ? > > and why is world =writable & readable= ? > > (hey, everybody, wanna know my passwd ?) > > It's not really a security hole because it lives inside a directory > that's mode 700 (unless you tampered with the default permissions > setup). in rh6.1 /var/lib/pgsql is 755 (and no, I haven't changed anything) can you spell "2_KM_DIAMETER_HOLE" ? > However, I agree it oughta be changed anyway. having a text file with usernames and *passwords in clear* world readable & writable make me feel nervous, pretty nervous. indeed the root user (who isn't the dba) can know anything too easy... -- -= Sergio A. Kessler == http://sak.org.ar =- You can have it soon, cheap and working; choose *two*.
"Sergio A. Kessler" <ser@perio.unlp.edu.ar> writes:
>> See doc/TODO.detail/pg_shadow.
> where ? can you post an absolute url ?
Sorry, I forgot that the TODO.detail files are not in the 6.5.*
distribution (they got added to the CVS repository since 6.5).
I'm not sure if they are available separately at the website (Bruce?).
I know you could get them by downloading a current snapshot...
>>>> and why is world =writable & readable= ?
>>>> (hey, everybody, wanna know my passwd ?)
>>
>> It's not really a security hole because it lives inside a directory
>> that's mode 700 (unless you tampered with the default permissions
>> setup).
> in rh6.1 /var/lib/pgsql is 755 (and no, I haven't changed anything)
> can you spell "2_KM_DIAMETER_HOLE" ?
In a standard setup, pg_pwd is inside .../pgsql/data which is mode 700.
Have the RH guys really blown it this badly? (Lamar?)
regards, tom lane
Tom Lane wrote: > > > in rh6.1 /var/lib/pgsql is 755 (and no, I haven't changed anything) > > can you spell "2_KM_DIAMETER_HOLE" ? > > In a standard setup, pg_pwd is inside .../pgsql/data which is mode 700. > Have the RH guys really blown it this badly? (Lamar?) .../pgsql/data !? I don't know who blown it, but I have: dir /var/lib/pgsql mode 755 (now 700 changed by me, hope I'm not breakingsomething) dir /var/lib/pgsql/base mode 700 (there is no one file here, just db-directories) files /var/lib/pgsql/pg_* mode 600 or 400 except pg_pwd :( wich seem pretty logical except the mode of pg_pwd (and the _clear_ passwds inside) (and that "base" should be called "data" :) -- -= Sergio A. Kessler == http://sak.org.ar =- You can have it soon, cheap and working; choose *two*.
On Fri, 19 Nov 1999, Tom Lane wrote: > > in rh6.1 /var/lib/pgsql is 755 (and no, I haven't changed anything) > > can you spell "2_KM_DIAMETER_HOLE" ? > > In a standard setup, pg_pwd is inside .../pgsql/data which is mode 700. > Have the RH guys really blown it this badly? (Lamar?) PGDATA is in fact 755 in the RPM installation. pg_pwd is the only file 666 under this directory. Since pg_pwd is not very well documented, it is kind of hard to figure out the permissions -- however, it is simple enough to issue a security advisory for people to chmod 0700 /var/lib/pgsql. The change to mode 0700 for PGDATA (which is moving in the future) will be made in future RPM's. Again, no other file under /var/lib/pgsql under RH6.1 has group or world permissions EXCEPT pg_pwd. And yes, this IS a glaring security hole, IF the user postgres has a postgres password. Just WHY is pg_pwd mode 666 in the first place?? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes:
> And yes, this IS a glaring security hole, IF the user postgres has a postgres
> password. Just WHY is pg_pwd mode 666 in the first place??
Because it's written out with a backend-side COPY operation, and
backend-side COPY makes *every* file it creates mode 666.
As I commented earlier in this thread, I think COPY ought not create
files with looser permissions than 644 (does anyone know why that's
not true already?). But that still wouldn't be good enough for pg_pwd.
Maybe it would be worthwhile to try to force pg_pwd in particular
to be written with just mode 600. In the standard configuration that
shouldn't make any difference ... but if people are going to use
hacked-up initdb code, as you evidently are doing, we probably should
not rely on the data directory to be locked up tightly...
regards, tom lane
On Sat, 20 Nov 1999, Tom Lane wrote: > As I commented earlier in this thread, I think COPY ought not create > files with looser permissions than 644 (does anyone know why that's > not true already?). But that still wouldn't be good enough for pg_pwd. > Maybe it would be worthwhile to try to force pg_pwd in particular > to be written with just mode 600. In the standard configuration that > shouldn't make any difference ... Hmmm... Can a parameter be passed to COPY giving the file create mode? A one-time hack to make pg_pwd only do something special sounds inelegant. >but if people are going to use > hacked-up initdb code, as you evidently are doing, we probably should > not rely on the data directory to be locked up tightly... Just 'initdb --pglib=/usr/lib/pgsql --pgdata=/var/lib/pgsql' /var/lib/pgsql is created during the rpm installation of the server rpm -- and I can force that to create mode 0700. HOWEVER, that just fixes the symptom -- not the problem. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes:
>> Maybe it would be worthwhile to try to force pg_pwd in particular
>> to be written with just mode 600. In the standard configuration that
>> shouldn't make any difference ...
> Hmmm... Can a parameter be passed to COPY giving the file create mode?
Yes, that was what I was thinking of. I need to look at the code and
see how direct the connection is between the code that knows it's
writing pg_pwd and the COPY code --- there might be a lot of layers
between :-(
> Just 'initdb --pglib=/usr/lib/pgsql --pgdata=/var/lib/pgsql'
> /var/lib/pgsql is created during the rpm installation of the server
> rpm -- and I can force that to create mode 0700. HOWEVER, that just
> fixes the symptom -- not the problem.
It looks like if you allow initdb to create the PGDATA directory, it
is correctly created with mode 700. But if the directory already
exists, initdb just uses it with whatever permissions it was made with.
Should initdb complain, or perhaps try to do a chmod() to make things
more secure? Mode 755 is bad enough, but suppose a sloppy admin had
made the directory group- or world-writable... or not even owned by
postgres...
regards, tom lane
On Sat, 20 Nov 1999, Tom Lane wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > Just 'initdb --pglib=/usr/lib/pgsql --pgdata=/var/lib/pgsql' > > /var/lib/pgsql is created during the rpm installation of the server > > rpm -- and I can force that to create mode 0700. HOWEVER, that just > > fixes the symptom -- not the problem. > It looks like if you allow initdb to create the PGDATA directory, it > is correctly created with mode 700. Won't work in the RPM context due to the user 'postgres' not having permissions to create the directory /var/lib/pgsql. (RPM installation must ordinarily be performed as 'root' -- so the RPM installation scripts can do the creation of the user 'postgres', as well as creation of the various executables, the PGLIB (/usr/lib/pgsql) directory, as well as PGDATA (/var/lib/pgsql). The initial run of the initscript (/etc/rc.d/init.d/postgresql) (run as root) does the initdb (as 'postgres') if the /var/lib/pgsql dir is empty. > Should initdb complain, or perhaps try to do a chmod() to make things > more secure? Mode 755 is bad enough, but suppose a sloppy admin had > made the directory group- or world-writable... or not even owned by > postgres... The RPM installation makes the directory automatically -- owned by user postgres, mode 755. A two byte change in the spec file and rebuilding the RPM's will fix this to mode 700 from the packaging end. HOWEVER, if someone already has the RPM's, all they need to do is run, as root, 'chmod 0700 /var/lib/pgsql' -- much quicker than a multimegabyte download of a new RPM set that contains no real fixes. Now, if a sloppy admin goes in and changes things after the installation, that is their own problem. For the RPM's, the fix is an %attr directive in the spec file during the build. For the tarball.... it seems you're heading the right direction. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
>> Hmmm... Can a parameter be passed to COPY giving the file create mode?
> Yes, that was what I was thinking of.
I have committed changes to current CVS that (a) ensure that pg_pwd
is written with mode 600, (b) reduce the permissions of other files
written by backend-side COPY to 644, instead of 666 as they were;
(c) if initdb is pointed at a pre-existing PGDATA directory, it does
chmod go-rwx on the dir to be sure its permissions are not too loose.
(As a free byproduct, this also verifies that the dir is owned by
postgres...)
I am not 100% comfortable with backpatching these changes into REL6_5,
however, since I had to change the way that the CREATE/ALTER USER
commands invoke COPY. So I think I will just leave them in the 7.0
code and not back-patch.
As an immediate fix, I suggest regenerating the RH RPMs so that
/var/lib/pgsql is created with mode 700 not 755.
regards, tom lane
Lamar Owen wrote: > The RPM installation makes the directory automatically -- owned by user > postgres, mode 755. A two byte change in the spec file and rebuilding the > RPM's will fix this to mode 700 from the packaging end. HOWEVER, if someone > already has the RPM's, all they need to do is run, as root, 'chmod 0700 > /var/lib/pgsql' -- much quicker than a multimegabyte download of a new RPM set > that contains no real fixes. maybe no real fixes ... but the current state is that we have a security hole more bigger than the crater of gorongoro. I agreed on doing just a chmod, but lots of people wouldn't do that, then you have to provide a smooth migration path in the next release, changing pgdata from 755 (created with the rpm) to 700. > Now, if a sloppy admin goes in and changes things after the installation, that > is their own problem. yup, but it was not me who chmod'ed 755 /var/lib/pgsql nor chmod'ed 666 pg_pwd, leaving all passwords in clear to all users on the system, not me ... -- -= Sergio A. Kessler == http://sak.org.ar =- You can have it soon, cheap and working; choose *two*.
"Sergio A. Kessler" wrote: > Lamar Owen wrote: > > already has the RPM's, all they need to do is run, as root, 'chmod 0700 > > /var/lib/pgsql' -- much quicker than a multimegabyte download of a new RPM set > > that contains no real fixes. > maybe no real fixes ... but the current state is that we have a > security hole more bigger than the crater of gorongoro. The phrasing 'no real fixes' was not a good phrasing on my part. It is a small fix that the sysadmin can apply much quicker by hand than by downloading and installing updated RPM's. The fix will go into the next release RPM set. There are some other open issues as well; they are on-list to go in the next release. > I agreed on doing just a chmod, but lots of people wouldn't do that, > then you have to provide a smooth migration path in the next release, > changing pgdata from 755 (created with the rpm) to 700. The chmod can and will be made part of the preinstall script in the RPM -- this is a much smaller difficulty than the whole upgrading mess solved in the 6.5.1-0.7lo prerelease RPM's. This will also be addressed in the next release. If demand is for a quick release, I can release within the week -- I am also working on integrating some other architectures into the RPM build (Cobalt RAQ and Qube MIPS architectures). > yup, but it was not me who chmod'ed 755 /var/lib/pgsql nor > chmod'ed 666 pg_pwd, leaving all passwords in clear to all > users on the system, not me ... Changing the mode of /var/lib/pgsql only fixes the symptom -- the problem (the mode 666 pg_pwd) is fixed in the current CVS and will appear fixed in 7.0. However, I do agree that the mode 755 in /var/lib/pgsql should have been fixed long ago -- it just wasn't noticed nor was it a known problem before. It will be fixed in the next RPM release. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11