Re: Starting postmaster in rc.local/during bootup

On Tue, 3 Dec 2002, Shridhar Daithankar wrote:

> On 3 Dec 2002 at 8:09, Chris Boget wrote:
> > Perfectly valid point.
> > However, when I need to do maintenence, I can simply go in and change the
> > shell then change it back.  That's very different from giving user postgres a
> > permanent shell.  And as I'd be rebooting (only because I'm still learning and not
> > because there might be problems with the system) more often than I'd be doing
> > maintenence on PG, I need to be able to get PG to start up during boot.
> > Perhaps I'm being overly paranoid but I've already been hacked once due to lax
> > security.  I'm just trying to cover all of my bases.
>
> To me it looks like,
>
> 1) You are the sole console user
> 2) Your machine is on internet.

Looks like that to me also. However, the simple first step to securing the
system is disable all services. Then start selectively enabling them. If it is
a remote system then obviously you'll need a way to log in, may be you need a
mail server also and presumably a way to get at the data in the DB (otherwise
what's the point of the system?). I find using xinetd in conjunction with
firewalling is a pretty good start and narrowing the service requests
honoured. The firewall is pretty essential if you're running services not run
from (x)inetd, like postgresql.

As you are a newbie to *nix I'd suggest the first thing to do after
installation is to scrap what gets configured by default and start from
scratch. At least for Linux distributions (I don't know how *BSD, Solaris etc.
come configured).

As an example, one of my servers has 9 services exported, and 3 of those are
internal network only, at least another two only work from specific
clients. This system provides all the functionality anyone from outside could
need from the system. Any other service requests are obviously probes and I've
even gone through a stage of just blocking entire network blocks from _all_
services when seeing such things. I don't worry about postgres user having a
valid log in shell on this system.

> In that case a shell for postgresql user is not much a threat since you alone
> will be having it's password. May be do not enable postgresql on network etc..

Besides, it doesn't need a password. One can always go through root to get to
the user. Although of course one could also view that transition through root
to be a problem.

> I don't think a simple way of doing it as postgresql is explicitly designed not
> to run as root. So you need postgres user and a shell for it.

The 'standard' way other daemons use is to have something like the
--user=<name> switch. Although these are also probably able to run as root and
the user change is seen as a security enhancment rather than a built in, is it
not reasonable for this sort of switch to be added to the
postmaster or postgres.conf?


--
Nigel J. Andrews