On Mon, 18 Apr 2005 20:07:04 +0200, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?= said: > The limit is only checked when process is created on a fork() call, but > during execution it's uid can change, thus, the limit for the new uid > could be exceed. The only two ways I can see this happening are (1) if the process is running as uid 0 (or capability-equivalent) at fork() time and have called set*uid() before execve(), or (2) we just exec'ed a set-UID binary. In both cases the "obvious" thing to do is to re-check the target UID's rlimit, but there may be some squirrelly corner case where this isn't true...
Attachment:
pgpsKta3Tk63Q.pgp
Description: PGP signature
- References:
- [PATCH] RLIMIT_NPROC enforcement during execve() calls
- From: Lorenzo Hernández García-Hierro <[email protected]>
- Re: [PATCH] RLIMIT_NPROC enforcement during execve() calls
- From: Christoph Hellwig <[email protected]>
- Re: [PATCH] RLIMIT_NPROC enforcement during execve() calls
- From: Lorenzo Hernández García-Hierro <[email protected]>
- [PATCH] RLIMIT_NPROC enforcement during execve() calls
- Prev by Date: Re: [PATCH 2.6.11.7 1/2] USB HID: Patch for Cherry CyMotion Linux keyboard
- Next by Date: Re: [PATCH 3/7] procfs privacy: misc. entries
- Previous by thread: Re: [PATCH] RLIMIT_NPROC enforcement during execve() calls
- Next by thread: dbench performance on cifs to Samba
- Index(es):
 |