Re: Starting postmaster in rc.local/during bootup - Mailing list pgsql-general
From | Nigel J. Andrews |
---|---|
Subject | Re: Starting postmaster in rc.local/during bootup |
Date | |
Msg-id | Pine.LNX.4.21.0212031504130.2423-100000@ponder.fairway2k.co.uk Whole thread Raw |
In response to | Re: Starting postmaster in rc.local/during bootup ("Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>) |
List | pgsql-general |
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
pgsql-general by date: