"Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes: > Hello Eric, > > On 07/21/2016 06:39 PM, Eric W. Biederman wrote: >> >> This patchset addresses two use cases: >> - Implement a sane upper bound on the number of namespaces. >> - Provide a way for sandboxes to limit the attack surface from >> namespaces. >> >> The maximum sane case I can imagine is if every process is a fat >> process, so I set the maximum number of namespaces to the maximum >> number of threads. >> >> I make these limits recursive and per user namespace so that a >> usernamespace root can reduce the limits further. If a user namespace >> root raises the limit the limit in the parent namespace will be honored. >> >> I have cut this implementation to the bare minimum needed to achieve >> these objectives. >> >> Does anyone know if there is a proper error code to return for resource >> limit exceeded? I am currently using -EUSERS or -ENFILE but both of >> those feel a little wrong. > > ENFILE certainly seems weird. I suppose my first question is: why two > different errors? EUSERS was there in the user namespace case for this condition (well nesting depth but same principle) so it made sense to start with. But too many users doesn't really make sense. ENFILE is actually slightly less insane. It actually is about hitting a resource limit, and seemed the most generic catchall we had. > Some alternatives you might want to consider: E2BIG, EOVERFLOW, > or (maybe) ERANGE. My problem with those is typically those are about the values in fields, not about creating too many things. So those really don't feel right. EACCESS or EPERM might be better but those are very very generic. I really want ETOOMANY or something like that. I am actually surprised given how common this pattern is, and the fact that rlimits have existed forever, that we don't have a resource limit exceeded error code. I suppose it might be worth looking at Posix to see if they have any suggestions. Perhaps it may even be time to add an appropriate error code to the list. Not the most important thing out of this patch series but something worth looking at. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
