Re: refusing connections based on load ...

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: refusing connections based on load ...
Дата
Msg-id 25243.988080642@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: refusing connections based on load ...  (The Hermit Hacker <scrappy@hub.org>)
Ответы 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))
Список 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 по дате отправления:

Предыдущее
От: Larry Rosenman
Дата:
Сообщение: Re: refusing connections based on load ...
Следующее
От: Larry Rosenman
Дата:
Сообщение: Re: refusing connections based on load ...