rlimits seem very heavy for a simple inherited boolean flag. Also, creating
a new one will require modifying a lot of delicate userland software.
Wouldn't some new prctl() flags be a better choice?
You're absolutely right that choosing to expose this functionality as an
rlimit (as opposed to as a new syscall or as a flag to an old syscall like
prctl()) is a decision with complex consequences.
I picked rlimits for this patch (after trying the "new syscall" approach
privately) because doing so provides exactly the interface, semantics, and
userland integration that I want:
interface: "unprivileged", "temporarily drop", "permanently drop", "get
current state", "persist current state across exec()", and some room for
future expansion of semantics by definining new state values between 0 and
RLIMIT_INFINITY.
integration: lots of sandboxing code already contains logic to drop rlimits
when starting up an isolated process. Furthermore, I think it would be really
great to be able to limit networking from the shell via ulimit and on a
per-user basis via /etc/security/limits.conf.
That being said, I'm not wedded to the decision. Could you give me some more
specific examples of the kinds of changes in low-level userspace code that
you're worried about?