Messages in this thread | | | Date | Sun, 13 Dec 2009 00:09:00 -0500 | From | Michael Stone <> | Subject | setrlimit(RLIMIT_NETWORK) vs. prctl(???) |
| |
Folks,
A colleague just asked me an excellent question about my approach which I'd like to share with you. Paraphrasing, he wrote:
> 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?
Here's my response:
> 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?
Regards,
Michael
| |