On Wed, Feb 23, 2022 at 10:00 AM Eric W. Biederman
<ebiederm@xxxxxxxxxxxx> wrote:
>
> Which brings us to the practical issues of how all of these things are
> wired together today.
I honestly think you should treat the limits as "approximate".
We do that for a number of reasons:
- sometimes we have racy tests because we don't want to do excessive
locking just for a limit: nobody cares if you can go a couple of
entries past a limit because you were lucky, it's important that you
can't go *much* past the limit.
- sometimes the limits themselves are fuzzy (example: time. it's
incremented by "ticks", but it's simply not that precise, and it
depends a bit when the ticks happen)
- sometimes it's ambiguous who we're talking about.
I think suid execs tend to fall in that third category. Be generous.
If the limit doesn't trigger at the suid exec, nobody cares. You want
to make sure it triggers eventually.
For example, let's say that you are the admin, and you made a mistake,
and you had a runaway fork() bomb that was caught by the limits.
Optimally, you still want to be able to be able to log in (one process
that was root when it did the fork(), and did a 'setresuid()' or
similar to drop the things, and then one process that does 'sudo' to
get privileges to kill the darn fork bomb).
See how that 'user' technically went over the limit, and that was A-OK!
Basic rule: it's better to be too lenient than to be too strict.
Linus
