Skip site navigation (1) Skip section navigation (2)

Re: refusing connections based on load ...

From: Ian Lance Taylor <ian(at)airs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: The Hermit Hacker <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: refusing connections based on load ...
Date: 2001-04-24 03:24:51
Message-ID: sioftnou7w.fsf@daffy.airs.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> 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.

On Linux you can get the load average by doing `cat /proc/loadavg'.
On NetBSD you can get the load average via a sysctl.  On those systems
and others the uptime program is neither setuid nor setgid.

> 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.

That is the way to do it on systems where obtaining the load average
requires special privileges.  But do you really need the load average
once a minute?  The load average printed by uptime is just as accurate
as the load average obtained by examining the kernel.

Ian

---------------------------(end of broadcast)---------------------------
TIP 652: Life is a serious burden, which no thinking, humane person would
wantonly inflict on someone else.
		-- Clarence Darrow

In response to

Responses

pgsql-hackers by date

Next:From: The Hermit HackerDate: 2001-04-24 04:20:42
Subject: Re: refusing connections based on load ...
Previous:From: Tom LaneDate: 2001-04-24 03:21:25
Subject: Re: refusing connections based on load ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group