Component
systemd-nspawn
Is your feature request related to a problem? Please describe
Running systemd-nspawn with --private-users managed --private-users-ownership foreign --directory /container/root --bind /host/directory.
/host/file will be owned by nobody user+group inside of the container. I couldn't find any option to map this to the container user range (the host directory is in the foreign range on the host just like --directory). As --directory is able to do this, I don't see why --bind wouldn't be able to.
Describe the solution you'd like
Add a new bind option like idmap (e.g. nsmap or nsmapforeign or privatemap) that will use the same logic as --directory (under --private-users managed --private-users-ownership foreign) for mounting the host directory it in the private user range.
Or if it's preferred a new --bind type (e.g. --bind-foreign or --bind-private).
I think it should follow the same logic as --directory (e.g. different behavior based on the --private-users set), that should allow it to share most of the code, making it easier to implement and maintain. Usually sharing the root --directory and any --bind files are desired to have the same security properties, so conceptually this also makes sense.
I'm not sure if --private-users-ownership should also be copied, I can see some users wanting to have a bind mount on the host that's in the standard map range instead of foreign, but keep their --directory inside of the foreign range, although it doesn't apply to my usecase. Foreign range would be used for files on the host that are bind into several container or just stored outside of the container root for other reasons, map range would be used for files to share with the host as well as container(s).
Describe alternatives you've considered
Only way I've been able to make it work is to manually chown the binded directory on the host into the transient container user namespace range after it's started.
The systemd version you checked that didn't have the feature you are asking for
260.1
Component
systemd-nspawn
Is your feature request related to a problem? Please describe
Running systemd-nspawn with --private-users managed --private-users-ownership foreign --directory /container/root --bind /host/directory.
/host/file will be owned by nobody user+group inside of the container. I couldn't find any option to map this to the container user range (the host directory is in the foreign range on the host just like --directory). As --directory is able to do this, I don't see why --bind wouldn't be able to.
Describe the solution you'd like
Add a new bind option like idmap (e.g. nsmap or nsmapforeign or privatemap) that will use the same logic as --directory (under --private-users managed --private-users-ownership foreign) for mounting the host directory it in the private user range.
Or if it's preferred a new --bind type (e.g. --bind-foreign or --bind-private).
I think it should follow the same logic as --directory (e.g. different behavior based on the --private-users set), that should allow it to share most of the code, making it easier to implement and maintain. Usually sharing the root --directory and any --bind files are desired to have the same security properties, so conceptually this also makes sense.
I'm not sure if --private-users-ownership should also be copied, I can see some users wanting to have a bind mount on the host that's in the standard map range instead of foreign, but keep their --directory inside of the foreign range, although it doesn't apply to my usecase. Foreign range would be used for files on the host that are bind into several container or just stored outside of the container root for other reasons, map range would be used for files to share with the host as well as container(s).
Describe alternatives you've considered
Only way I've been able to make it work is to manually chown the binded directory on the host into the transient container user namespace range after it's started.
The systemd version you checked that didn't have the feature you are asking for
260.1