linux-kernel - Re: [PATCH 0/3] extend get/setrlimit to support setting rlimits external to a process (v5)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 12 Oct 2009 20:06:01 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, marcin.slusarz@...il.com
Subject: Re: [PATCH 0/3] extend get/setrlimit to support setting rlimits
	external to a process (v5)

On Mon, Oct 12, 2009 at 02:58:10PM -0700, Andrew Morton wrote:
> On Mon, 12 Oct 2009 12:13:42 -0400
> Neil Horman <nhorman@...driver.com> wrote:
> 
> > Its been requested often that we have the ability to read and modify process
> > rlimit values from contexts external to the owning process.  Ideally this allows
> > sysadmins to adjust rlimits on long running processes wihout the need to stop
> > and restart those processes, which incurs undesireable downtime.  This patch
> > enables that functionality,  It does so in two places.  First it enables process
> > limit setting by writing to the /proc/pid/limits file a string in the format:
> > <limit> <current limit> <max limit> > /proc/<pid>/limits
> > where limit is one of
> > [as,core,cpu,data,fsize,locks,memlock,msgqueue,nice,nofile,nproc,rss,rtprio,rttime]
> > 
> > Secondly it allows for programatic setting of these limits via 2 new syscalls,
> > getprlimit, and setprlimit, which act in an identical fashion to getrlimit and
> > setrlimit respectively, except that they except a process id as an extra
> > argument, to specify the process id of the rlimit values that you wish to
> > read/write
> 
> I'm still not seeing why we need the /proc interface.
> 
> We've been using a syscall to set rlimits for ever and we've survived.
> 
Except that we haven't.  We've had the read side of the proc interface for years
now, simply because people asked for it.  We could have add getprlimit back
then, but we didn't because users liked this.  Its easy, its obvious, and and it
doesn't require a sysadmin to remember the name of another utility.

> It just adds bloat and complexity to the kernel because putting a
> 100-line tool into util-linux is All Too Hard.
> 
And, with the adjustments to support the getprlimit/setprlimit syscalls in this
series, the net additional code to support a writeable /proc interface totals
about 80 lines.  I really think 'bloat' is a bit of an overstatement here.  If
you're really that worried about it, we can surround the proc interface with a
config option.  But at this point people have become acoustomed to having
/proc/pid/limits available, I don't see why 80 lines to add the ability to set
limits is really that much of a barrier.

Neil

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/