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
