From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Gibson To: passt-dev@passt.top Subject: Re: [PATCH] RFC: Remove unusable --netns-only option Date: Wed, 20 Jul 2022 12:45:26 +1000 Message-ID: In-Reply-To: <20220719223925.617bdb92@elisabeth> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2021474767971054509==" --===============2021474767971054509== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 19, 2022 at 10:39:25PM +0200, Stefano Brivio wrote: > On Tue, 19 Jul 2022 16:23:10 +1000 > David Gibson wrote: >=20 > > The intended semantics of --netns-only are pretty unclear to me. It's > > intended for pasta, but it's not clear whether its saying the spawned she= ll > > should only enter the target netns, or that the passt/pasta packet > > forwarding process should only sandbox itself in a network namespace, not > > a user namespace. >=20 > The latter. I think this is marginally more clear in the man page, but needs > indeed a better explanation. Definitely. At present it also appears to affect the spawned shell as well, it a rather counter-intuitive way. > > In any case, as far as I can tell there's not actually any case in which > > the --netns-only option will work. If nothing else, we will always fail > > in sandbox(), because it attempts a number of operations which require > > CAP_SYS_ADMIN in our current user namespace. We drop all capabilities in > > our initial user namespace when we start, so the only way we can have > > CAP_SYS_ADMIN at this point is if we've joined a new user namespace, which > > we won't do with --netns-only. > >=20 > > For pasta joining an existing namespace (the apparently intended use case= ), we'll actually fail before > > we'll fail before we get to that point: in conf_ns_check() we'll attempt > > to join the target network namespace. This also requires CAP_SYS_ADMIN in > > both our current user namespace and the user namespace which owns the > > target network namespace. Again, since we've dropped capabilities in our > > original namespace this will never be the case. >=20 > ...however, we can also have UID 0 in a non-init user namespace, and > that will work. Hrm.. I thought being UID 0 just meant we started with all the capabilities, so once we've explicitly dropped them we still won't be able to do this. That seemed to be what happened when I tried running it as root. > This is what happens in the Podman integration case. Unfortunately the > demo is broken at the moment (I had to rebase the patch with a bit of > care, I'll publish the updated one soon). Can you explain a bit more about what the podman use case is, and why it requires the netns only logic? > > For pasta creating its own network namespace we'll fail for a similar > > reason in yet another place. This time we'll fail in nl_sock_init() again > > because we attempt to enter the new network ns via NS_CALL without having > > regained CAP_SYS_ADMIN by joining a new user namespace. Because this > > happens after spawning the shell, it results in a weird failure mode, whe= re > > the pasta spawned shell is running, but pasta isn't actually handling > > packets. Exiting the shell will lead to a hang until the process is > > explicitly killed. >=20 > Ouch, I didn't think of this. >=20 > Anyway, let me get back to you in a couple of days on the whole issue. > The usage is there, albeit poorly documented, with a broken demo, and > no handling of (kind of) corner cases. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --===============2021474767971054509== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUVCQ0FBZEZpRUVvVUx4V3U0L1dz MGRCK1h0Z3lwWTRnRXdZU0lGQW1MWGJEQUFDZ2tRZ3lwWTRnRXcKWVNJNWtRLy9kazVFZDJyUFNz THlDRG4wYVc2MEgzci9FTmoxL3RadW9Rd21BV2VjWGkxSXA2N2NUNlJEVDVCNwpXYldsR1k1RXAy YWdjZzRMZ1FCd2lDQmY5ZzdkOVhsaWhicHZXeUFTQ3lEd3M5QzFVRjZsSjliQXRVNkorV2g1CmV4 cUx2ZHJNamk2Z213T2cwNlI2cWVLdWkveFBMQU4wVmZBZ0EvbVNkZVhROUU1RTU0Wkx0OHNadzd3 WnpsZTIKMVNPRS9hdFBlenBGOXpCcyszeUFLSE0xN2I3eU5MaTNuYnlSbUNSU3YyY0Mxb1BLcU02 dS9Ed1R0emw5anA0Qwo5RmNtZUduMUE0ck5meGNZVnlLNWNwdGQyazBpMnRiaE42WURuWDJJZ2Zx M0duajdqSlhudVJ4R3g0ZUZyYVVxCnVGUjJLQ0tXY0UzVGVYSjg3ZzNZb1EzQnN3V2dTVVhGMHdB cDlVSUZEK1h5U3QvaHpRV3ZoZERjM2V1ZUtubmgKU2Z2Y3ovTG0zRk1mY3d5SVIzZGVVZy9SSEJj VW14NnhvVmJxR0lEM2p3bWlhdjBBL1UwUFpEL0phMDd4a3pMaQpYR0FmbjcyTFVGS2haRitYQ2N1 NVVuZEpYZkJNcngvWkxWNEJhYjg1QUQ2bzJ2Yk9Ddmthd2pObStnaFFVMUpRClF5b0g4bWFqUkNt bGtXcFYxeHBNZjFjbGhFeUNiVjB3b3ZraGlTVDR1UVVLUTJOWm9iQllYVlQ2UnMwMS9SU3YKRzJa VjVCdit4Z3dxWjNzY2dIejczTHl2STE2QW9BakhCOTNXL1VkM0t4WnZZd3ZrWGtBNlJTak1DTC92 UnQvcApnVmxmZ0w0UnBLV05DWXJCTVh1bmtIQWxOK3BrMDUzcWw4bmlDbVY4L08vcHYvOHh5L3c9 Cj1nRjRuCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============2021474767971054509==--