On Wed, Feb 23, 2022 at 5:24 PM Eric W. Biederman ebiederm@xmission.com wrote:
Question: Running a suid program today charges the activity of that program to the user who ran that program, not to the user the program runs as. Does anyone see a problem with charging the user the program runs as?
So I think that there's actually two independent issues with limits when you have situations like this where the actual user might be ambiguous.
- the "who to charge" question
- the "how do we *check* the limit" question
and honestly, I think that when it comes to suid binaries, the first question is fundamentally ambiguous, because it almost certainly depends on the user.
Which to me implies that there probably isn't an answer that is always right, and that what you should look at is that second option.
So I would actually suggest that the "execute a suid binary" should charge the real user, but *because* it is suid, it should then not check the limit (or, perhaps, should check the hard limit?).
You have to charge somebody, but at that point it's a bit ambiguous whether it should be allowed.
Exactly so that if you're over a process limit (or something similar - think "too many files open" or whatever because you screwed up and opened everything) you could still log in as yourself (ssh/login charges some admin thing, which probably has high limits or is unlimited), and hopefully get shell access, and then be able to "exec sudo" to actually get admin access that should be disabled from the network.
The above is just one (traditional) example of a fork/open bomb case where a user isn't really able to no longer function as himself, but wants to fix things (maybe the user has another terminal open, but then he can hopefully use a shell-buiiltin 'kill' instead).
And I'm not saying it's "the thing that needs to work". I'm more making up an example.
So I'm only saying that the above actually has two examples to the two sides of the coin: "login" lowering privileges to a user that may be over some limit - and succeeding despite that - and 'suid' succeeding despite the original user perhaps being over-committed.
So it's intended exactly as an example of "picking the new or the old user would be wrong in either case if you check limits at the transition point".
Hmm?
Linus