due to something which I consider to be a kernel bug it's
impossible for pam to do its job and set the per-user
RLIMIT_NPROC (number of processes limit) to something which
is lower than the amount of processes root is running at that
moment.
At least, it fails with all programs which set RLIMIT_NPROC
and fork()+exec() afterwards.
The attached patch should bring us back to the behaviour we
had in 2.2. Comments?
regards,
Rik
-- Executive summary of a recent Microsoft press release: "we are concerned about the GNU General Public License (GPL)"http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/
--- kernel/fork.c.orig Fri Jun 22 20:27:27 2001 +++ kernel/fork.c Fri Jun 22 20:52:41 2001 @@ -576,7 +576,14 @@ *p = *current;
retval = -EAGAIN; - if (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur) + /* + * Check if we are over our maximum process limit, but be sure to + * exclude root. This is needed to make it possible for login and + * friends to set the per-user process limit to something lower + * than the amount of processes root is running. -- Rik + */ + if (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur + && !capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE)) goto bad_fork_free; atomic_inc(&p->user->__count); atomic_inc(&p->user->processes);
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/