Re: enforcing RLIMIT_NPROC in setuid() ?

[christos%zoulas.com@localhost (Christos Zoulas)]

On Jan 10,  4:15pm, eravin%panix.com@localhost (Ed Ravin) wrote:
-- Subject: Re: enforcing RLIMIT_NPROC in setuid() ?

| > The problem is that if you carry the UID change, then you effectively
| > exceed the limit so if the program does not check the return value
| > you end up back to square one. If you don't change the UID, then
| > you can cause security problems.
| 
| That's what I was thinking.  It does no harm to have setuid() return
| an error if it still carries out the UID change - properly-written
| programs would error off immediately, dumb programs would do what
| they did before and carry on as the expected non-root user, without
| any new security problems (unlike the Linux example referred to above,
| where the program ran as root while it thought it had changed to non-root)..

Yes, except that it is a somewhat counter-intuitive to return an error,
and do the action. I cannot think of another instance where a system call
does this.

| > Yet another is to do the checking on exec, i.e. let
| > root fork() and setuid(), but enforce the limit on exec().
| 
| This is more effective, since it will catch all of the common cases,
| like sshd and cron.  It should catch all the cases of accidental
| overflow of the process limit, as my customer did.
| 
| But a program could be taking actions after setuid() and before exec(),
| such as reading in a user-created initialization file.  Modifying
| setuid() gives us a chance to catch those too, but only a chance
| since the program could ignore the return value.

Yes, it can. But what's the harm in that except that it will waste a
few more cycles? The biggest problem I see with the change is that
a process that did not exceed the quota can be penalized about it.
Consider the case where a root daemon forks, runs setuid and sleeps
bringing the user above the NPROC resource limit. Then if a different
shell process tries to exec, it will fail.

| Should I open a up a PR on this?

Sure.

christos