I think this is viable for using ranges > 1 in user namespaces with rootless containers (as long as it is optional).

269/275 passed on RHEL - Failed.
259/273 passed on CentOS - Failed.
273/274 passed on Fedora - Failed.
Log - https://aos-ci.s3.amazonaws.com/opencontainers/runc/runc-integration-tests-prs/329/fullresults.xml

We pushed some more commits to avoid shelling out, and to ensure that tests pass on both Travis and Jenkins.

The new flags we added are currently global, in a similar way to --criu. Would it make more sense to move these to flags of create and run only?

Maintainers, do you have any other thoughts?

I don't really like this because it dilutes what "rootless containers" means by conflating "proper" rootless containers with containers that are started with privileged helpers -- this is one of the reasons that cgroups were punted on rather than going the LXC route and using their cgroup helpers. I'm wondering if there's some other way of implementing this integration that doesn't cause this dilution (I'd hope that you could do it with some additional hooks but I'm unsure how easy it would be to implement this).

I'm going to review this more thoroughly though.

Fwiw I don't think anything in this PR conflicts with the rootless use case any more than the fact runc already supports running as root as well as rootlessly conflicts with it. In the case where you have permissions (either because you're root or because you're doing a 1:1 mapping) no setuid binary is needed. This is just adding support for the OS-supported-and-secured newuidmap binary to allow a non-root user to be delegated the ability to use runc in a particular mapping range (via the standard /etc/subuids mechanism) without being given the generic ability to create containers for arbitrary uid ranges.

Tbh given /etc/subuids / newuidmap etc are shipped by major OSes it seems pretty odd for runc not to support using them.

@julz

In the case where you have permissions (either because you're root or because you're doing a 1:1 mapping) no setuid binary is needed.

Yeah, I understood as much. But this split in functionality is (IMO) harder to make obvious than the root-or-not-root modes. As I said though, I'll mess around with this some more.

Tbh given /etc/subuids / newuidmap etc are shipped by major OSes it seems pretty odd for runc not to support using them.

Sure, but my view on those is soured by how Docker handled their user namespace story (we had to go through a bunch of pain to update shadow on all of our distributions so that Docker's user namespace support would work nicely). As I said, I'll think about it some more.

@cyphar Any further thoughts on this? Appreciate you are extremely busy, such is the life of a maintainer 😆

Sorry for letting this stagnate. There are several bits from this PR that I like but several bits from #1529 that I like as well. I'll read through this PR again and then we'll carry over the nice parts into #1529.

Does that sound okay @teddyking @williammartin? Again, sorry for not touching this for a while, my GitHub notifications are several pages long these days. I'm currently reworking my email setup so that I can more sanely handle GitHub notifications.

@cyphar Sure, that sounds good. We're happy to work with #1529 and hopefully can make sure that it matches functionality with this. No problem on the delay.

Closing in favour of #1529, which I've modified to include most of the changes here (as well as making the testing scheme much nicer and extensible for the cgroup changes in #1540.

Thanks @teddyking and @williammartin (and everyone else) for your contributions!