Alternative solution for #132

I'm not sure this can be alternative, because setting file capabilities in user namespace is not supported for Kernel < 4.14

I'm not sure this can be alternative, because setting file capabilities in user namespace is not supported for Kernel < 4.14

thinking more of it: the two solutions are not really complementary to each other, they can be both used and they address the issue in a different way.

thinking more of it: the two solutions are not really complementary to each other, they can be both used and they address the issue in a different way.

When compiling it needs to be suid xor fscaps.

@AkihiroSuda

Alternative solution for #132

I'm not sure this can be alternative, because setting file capabilities in user namespace is not supported for Kernel < 4.14

Where does this matter?

I presume if you are playing with a container and you are dropping capabilities you are doing so because you have real root inside the container. As such what you can do inside a user namespace should not be relevant.

Further file capabilities set outside of a user namespace continue to work inside the user namespaces on any kernel that supports user namespaces. The binaries that use file capabilities are just then limited to having those file capabilities inside the user namespace in which they run.

I opened PR #137 before I saw this, sorry.

Please update configure.ac to ensure that setcap is installed before doing everything else.

Then assuming you've test-built this with and without filecaps flag, I'll merge this one.

Please update configure.ac to ensure that setcap is installed before doing everything else.

I've pushed an updated version where I've added a check for setcap

I'm not sure this can be alternative, because setting file capabilities in user namespace is not supported for Kernel < 4.14

Where does this matter?

It matters

• when building a rootfs image (especially for containers but not limited to) with newuidmap/newgidmap binaries in a user namespace. e.g. building an image of img using img itself.
• when unpacking a rootfs archive with newuidmap/newgidmap binaries in a user namespace

I presume if you are playing with a container and you are dropping capabilities you are doing so because you have real root inside the container.

No

I'm also wondering there might be some container builder & runtime implementations that does not support filecaps?

I'm also wondering there might be some container builder & runtime implementations that does not support filecaps?

In general they would be non-OCI compliant or just not a useful runtime (most distributions use fscaps for /usr/bin/ping). But AUFS would have some issues since it has "interesting" xattr support -- but AUFS has many other issues and I don't think it makes much sense to accommodate it given that very few people use it nowadays.

@brauner @hallyn should we default to installing with file caps? I am not really sure what the default should be :)

@giuseppe, default to setuid for now and in a year when namespaced file caps have found even more adoption and the new LTS kernel is out we make an announcement and make fscaps the default. We can announce in this release that we plan on switching over new*idmap to fscaps in the next release.

@brauner That makes sense, thanks for the clarification. Could we reconsider #132 in the meanwhile since newuidmap/newgidmap will still be used as suid binaries for now?