user units: implicitly enable PrivateUsers= when sandboxing options are set

[bluca]

Enabling these options when not running as root requires a user namespace, so implicitly enable PrivateUsers=.

[poettering]

Would a new PrivateUser=identity concept work for this too? i.e. a userns that is private to the service, but just a full identity mapping?

[bluca]

Would a new PrivateUser=identity concept work for this too? i.e. a userns that is private to the service, but just a full identity mapping?

It turns out it cannot be done from the user manager, as it requires privileges to set up an id map of more than the current uid

[DaanDeMeyer]

Would a new PrivateUser=identity concept work for this too? i.e. a userns that is private to the service, but just a full identity mapping?

It turns out it cannot be done from the user manager, as it requires privileges to set up an id map of more than the current uid

@brauner and @poettering had the idea to add a service to manage uid/gid ranges that would hand out user namespaces with a uid/gid range and idmapping configured to tools and services. Rootless nspawn would make use of this. I wonder if we could use the same service here to get an identity mapping without needing privileges? Not sure about the security implications though.

[bluca]

Would a new PrivateUser=identity concept work for this too? i.e. a userns that is private to the service, but just a full identity mapping?

It turns out it cannot be done from the user manager, as it requires privileges to set up an id map of more than the current uid

@brauner and @poettering had the idea to add a service to manage uid/gid ranges that would hand out user namespaces with a uid/gid range and idmapping configured to tools and services. Rootless nspawn would make use of this. I wonder if we could use the same service here to get an identity mapping without needing privileges? Not sure about the security implications though.

If it worked it could be retrofitted to use it yes - but it can be done later

[bluca]

Would a new PrivateUser=identity concept work for this too? i.e. a userns that is private to the service, but just a full identity mapping?

It turns out it cannot be done from the user manager, as it requires privileges to set up an id map of more than the current uid

@brauner and @poettering had the idea to add a service to manage uid/gid ranges that would hand out user namespaces with a uid/gid range and idmapping configured to tools and services. Rootless nspawn would make use of this. I wonder if we could use the same service here to get an identity mapping without needing privileges? Not sure about the security implications though.

mmh I tried this, but when the receiving end of the namespace FD is not the same uid, I get -EPERM back from setns(fd, CLONE_NEWUSER), any idea what else needs to be done?

[brauner]

Would a new PrivateUser=identity concept work for this too? i.e. a userns that is private to the service, but just a full identity mapping?

It turns out it cannot be done from the user manager, as it requires privileges to set up an id map of more than the current uid

@brauner and @poettering had the idea to add a service to manage uid/gid ranges that would hand out user namespaces with a uid/gid range and idmapping configured to tools and services. Rootless nspawn would make use of this. I wonder if we could use the same service here to get an identity mapping without needing privileges? Not sure about the security implications though.

mmh I tried this, but when the receiving end of the namespace FD is not the same uid, I get -EPERM back from setns(fd, CLONE_NEWUSER), any idea what else needs to be done?

Just summarizing what I explained elsewhere just now. To make this work you should have the acquire_userns() function setuid to the client's uid that requested the userns creation, then create the userns, and then have the parent write the mapping that you want. This ensures that the client owns the userns. It's also important that the client and the creator of the userns are located in the same userns - the actual restriction is a bit more detailed but it doesn't matter here - so if you do nested userns creation then you should take the client's userns into account so the parent userns relationship is correctly set up. Also, you should be ON HOLIDAY. STEP AWAY FROM THE COMPUTER.

[bluca]

Also, you should be ON HOLIDAY. STEP AWAY FROM THE COMPUTER.

That's why I have time to do the cool stuff! Beer-fueled hacking go brrrr

[keszybz]

I think we should merge this.

The only open issue is how to handle ProtectKernelModules= and other settings that are partially implemented via seccomp. Lennart's approach gives slightly better backwards-compat, and Luca's approach (current patch) gives slightly more reasonable behaviour for users. I think we should be fine with the latter because of the preparatory work that was done: queries in distros and on the mailing list. The expectation is that that units that would be affected by this are very rare or nonexistent. Of course we will need to announce this in NEWS, etc, but I think we can get away with this. Let's merge this now, while there is still some time before the next release, to give it some time to "bake".

Needs a rebase and typo fixes.

[keszybz]

CentOS CI (Arch Linux) fails deep in TEST-75-RESOLVED. But I don't think this is related, the unit is up and running when the failure happens.

[keszybz]

jammy-ppc64el: TEST-29-PORTABLE: FAIL (1809 s)