Subject: Re: check resource limits with exec(3)?
To: Jeremy C. Reed <>
From: Bill Studenmund <>
List: tech-userlevel
Date: 06/14/2006 14:54:28
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 06, 2006 at 11:10:01AM -0700, Jeremy C. Reed wrote:
> On Mon, 5 Jun 2006, Greg A. Woods wrote:
> > > What is the procedure for checking resource limits when the process is
> > > started as root with a fork and then uses setuid to change user?
> > >=20
> > > Should exec(3) check if the resource limit (like maxproc) has already=
> > > reached?
> >=20
> > No, it had better not do so, especially not maxproc.  Calls to the
> > exec() family of functions do not change the number of processes that
> > are running.
> >=20
> > It is also critical that one be able to exec another program when one is
> > already running maxproc processes.
> Maybe add a new exec()-type function that checks limits? Probably not,=20
> since that would not be portable.

I too don't like this.

> Here is the problem: A program running as root is forked and has the=20
> resource limitations as allowed for root. The new child process's=20
> resources are changed using setusercontext() including changing the=20
> running group id and user id. Then it execle() to run a different process=
> as this new user -- this is allowed even if over the maximum allowed=20
> maxproc for that user.
> I think a fix for this problem would be to do a double fork. Do the secon=
> fork after the setusercontext(). This second fork will correctly fail if=
> over the maxproc for example. (And examples of doing a double fork for=20
> this purpose?)
> Or should a userland program check the resource settings itself? (Any=20
> examples of that?)

I think the program should check resource settings itself.

> Or is it acceptable for programs to go over (ignore) the defined maxproc?

I think it can, at (different) times, be both acceptable and unacceptable
to go over the limit. I can both see the advantage of root opting to let a
user go over a limit, and also the fact that we probably want login to not
let a user over the limits.

Thus I think userland really has to have a call it can make, and call it=20
when needed.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)