On Tue, 2016-10-25 at 20:22 +0200, Jann Horn wrote: > On Tue, Oct 25, 2016 at 11:13:24AM -0700, James Bottomley wrote: > > On Tue, 2016-10-25 at 18:30 +0100, David Howells wrote: > > > James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > I think you want to behave exactly as the mount namespace does: > > > > on > > > > initial clone, you get a fully cloned mount tree and then you > > > > customise it by unmounting pieces. > > > > > > That adds quite a bit of complexity, given that: > [...] > > > (2) there are quotas on the number of keys a user is permitted; > > > > If this is counted per-id, then yes, mapping a range of ids with an > > owning exterior non root user does allow you to escape the count > > ... how important is it? Could we not simply hand wave it away as > > yet another consequence you have to think about when giving a user > > a range of exterior ids (because if there are N, their key count > > could get up to N * the limit). > > Wouldn't it be N * normal_limit * number_of_namespaces, where > number_of_namespaces is how many namespaces you can create (afaik > unbounded)? I need to understand why we have a limit first. The above was assuming it's something simple like an arbitrary limit to prevent resource exhaustion. but, assuming that again ... I was thinking enforce the limit by exterior uid (kuid), so it becomes number of uids a user owns * normal_limit. It wouldn't vary based on the number of namespaces you create. James _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
