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 ...
Re: refusing connections based on load ... Re: refusing connections based on load ... Re: refusing connections based on load ... |
Список | 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 по дате отправления: