aboutgitcodebugslistschat
path: root/tap.c
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2022-10-14 15:25:36 +1100
committerStefano Brivio <sbrivio@redhat.com>2022-10-15 02:10:36 +0200
commiteb3d03a588e8a246a30017add08c79527fa9a6a3 (patch)
tree0afa2ecef4f28800b931310caea62dbc841941c4 /tap.c
parentfb449b16bd8ccf8b751dfa5aee54cb7de0525706 (diff)
downloadpasst-eb3d03a588e8a246a30017add08c79527fa9a6a3.tar
passt-eb3d03a588e8a246a30017add08c79527fa9a6a3.tar.gz
passt-eb3d03a588e8a246a30017add08c79527fa9a6a3.tar.bz2
passt-eb3d03a588e8a246a30017add08c79527fa9a6a3.tar.lz
passt-eb3d03a588e8a246a30017add08c79527fa9a6a3.tar.xz
passt-eb3d03a588e8a246a30017add08c79527fa9a6a3.tar.zst
passt-eb3d03a588e8a246a30017add08c79527fa9a6a3.zip
isolation: Only configure UID/GID mappings in userns when spawning shell
When in passt mode, or pasta mode spawning a command, we create a userns for ourselves. This is used both to isolate the pasta/passt process itself and to run the spawned command, if any. Since eed17a47 "Handle userns isolation and dropping root at the same time" we've handled both cases the same, configuring the UID and GID mappings in the new userns to map whichever UID we're running as to root within the userns. This mapping is desirable when spawning a shell or other command, so that the user gets a root shell with reasonably clear abilities within the userns and netns. It's not necessarily essential, though. When not spawning a shell, it doesn't really have any purpose: passt itself doesn't need to be root and can operate fine with an unmapped user (using some of the capabilities we get when entering the userns instead). Configuring the uid_map can cause problems if passt is running with any capabilities in the initial namespace, such as CAP_NET_BIND_SERVICE to allow it to forward low ports. In this case the kernel makes files in /proc/pid owned by root rather than the starting user to prevent the user from interfering with the operation of the capability-enhanced process. This includes uid_map meaning we are not able to write to it. Whether this behaviour is correct in the kernel is debatable, but in any case we might as well avoid problems by only initializing the user mappings when we really want them. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'tap.c')
0 files changed, 0 insertions, 0 deletions