Re: refusing connections based on load ... - Mailing list pgsql-hackers

From Tom Lane
Subject Re: refusing connections based on load ...
Date
Msg-id 25243.988080642@sss.pgh.pa.us
Whole thread Raw
In response to Re: refusing connections based on load ...  (The Hermit Hacker <scrappy@hub.org>)
Responses Re: refusing connections based on load ...  (Larry Rosenman <ler@lerctr.org>)
Re: refusing connections based on load ...  (Ian Lance Taylor <ian@airs.com>)
Re: refusing connections based on load ...  (The Hermit Hacker <scrappy@hub.org>)
Re: refusing connections based on load ...  (ncm@zembu.com (Nathan Myers))
List pgsql-hackers
The Hermit Hacker <scrappy@hub.org> writes:
> On Mon, 23 Apr 2001, Tom Lane wrote:
>> sendmail expects to be root.

> Actually, not totally accurate ... sendmail has a 'RunAs' option for those
> that don't wish to have it run as root,

True, it doesn't *have* to be root, but the loadavg code still requires
privileges beyond those of mere mortals (as does listening on port 25,
last I checked).

On my HPUX box:

$ ls -l /dev/kmem
crw-r-----   1 bin        sys          3 0x000001 Jun 10  1996 /dev/kmem

so postgres would have to run setuid bin or setgid sys to read the load
average.  Either one is equivalent to giving an attacker the keys to the
kingdom (overwrite a few key /usr/bin/ executables and wait for root to
run one...)

On Linux and BSD it seems to be more common to put /dev/kmem into a
specialized group "kmem", so running postgres as setgid kmem is not so
immediately dangerous.  Still, do you think it's a good idea to let an
attacker have open-ended rights to read your kernel memory?  It wouldn't
take too much effort to sniff passwords, for example.

Basically, if we do this then we are abandoning the notion that Postgres
runs as an unprivileged user.  I think that's a BAD idea, especially in
an environment that's open enough that you might feel the need to
load-throttle your users.  By definition you do not trust them, eh?

A less dangerous way of approaching it might be to have an option
whereby the postmaster invokes 'uptime' via system() every so often
(maybe once a minute?) and throttles on the basis of the results.
The reaction time would be poorer, but security would be a whole lot
better.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Larry Rosenman
Date:
Subject: Re: refusing connections based on load ...
Next
From: Larry Rosenman
Date:
Subject: Re: refusing connections based on load ...