From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Gibson To: passt-dev@passt.top Subject: Re: [PATCH v2 04/10] Safer handling if we can't open /proc/self/uid_map Date: Sat, 10 Sep 2022 17:23:25 +1000 Message-ID: In-Reply-To: <20220909163352.50b566ab@elisabeth> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8618546867852747870==" --===============8618546867852747870== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, Sep 09, 2022 at 04:33:52PM +0200, Stefano Brivio wrote: > On Thu, 8 Sep 2022 13:59:01 +1000 > David Gibson wrote: > > > passt is allowed to run as "root" (UID 0) in a user namespace, but notas > > real root in the init namespace. We read /proc/self/uid_map to determine > > if we're in the init namespace or not. > > > > If we're unable to open /proc/self/uid_map we assume we're ok and continue > > running as UID 0. This seems unwise: AFAIK the only instance in which > > uid_map won't be available is if we're running on a kernel which doesn't > > support user namespaces, in which case we won't be able to sandbox > > ourselves as we want and fail anyway. > > Well, if user namespaces are not supported and the UID is 0, then we're > actually running as root, so we should quit anyway. Right, that's kind of the whole point of this patch, but it's a bit obscured in the wording here because I realized we'd actually fail later anyway. > > If there are other circumstances > > where it can't be opened it seems marginally more likely that we *are* > > in the init namespace. > > That could also happen if procfs is not mounted, but I'm not sure what > would work then. True. I'll reword the commit message to make both points clearer. > > Therefore, fail with an error in this case, instead of carrying on. > > Yes, absolutely. > -- 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 --===============8618546867852747870== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUVCQ0FBZEZpRUVvVUx4V3U0L1dz MGRCK1h0Z3lwWTRnRXdZU0lGQW1NY08yY0FDZ2tRZ3lwWTRnRXcKWVNLYlh4QUFuZzhBU0hxaEpl Ym9PTm1mTytpeW5YMnlWemd5bG1ieXJwcG9yZVVMbUgySVNFWnZXaHNSNTdYawpVcVZ2NXJ5U3lo czNWWGFyVHNsRWlodDcyaHFNMXJHdnlPT0hRZUZZbTNnaURxR1dTUzkzMVk5UllZaC9TMG1vCjlO ZmxrcVN3UDIxdnlPY25zeEUzd2F1YUNIeGFxR0puU1RRQ3dOSmJZZXUxSWlyMWt2bEY1YmhMZkRB Q0IwSFUKS0tiTXFuSWg0UUF0WnpDL05MLzdzK3Q3MGRHN0xIRDlIdUcwQWIxN0VGSmlQRy9BeHFC bWpDenhmRVVzbEduTwp0RUdpb3ZWNjEyTEEyTytUb3EydWNwNXFFN0Q5OUJsc2t2V20rZjgwaHh3 NVZVa0VvTlNLM21rV3RZTitxZ0EyCnhPOXIwNDNaa3Q1TWtLdlc2RWV5ODhoZ0x3QTdBY0RLZUJS dGdCdzNJM0ZCODhqa2g5NnhWTWw2aU93VjIzVmIKaXI4bVkyeFlQL1pZVXNSM1crbDNJWERHbTZB UnY1QkFBeGRkWXRuQlVnZmMzaDJRQklSdzY1TGxkS0lxQnV6TApnTkhRdE1HQU1FQkNValQ0SlZV a1FBVnRBNk1PbmVxcnRxOXMyelEvbHJDYlhoSWphQjhKenZoQ1ZtSjg1eTBxCjIrakROOVZ0czVD V01kd3FzSmdRZ2dORER4dGpzZm1pdnVuS0VtTEwvdkhqQkFmQStLSzZtVjdqMmxhQmp1THAKK3pw Wlhoa2hEY1kzSU9uWENpS25QaDN1UWtWV21mT2pyOFdZajhNcTVoaXdPbTU3NVc5RjFhb1UxNXBp VisrbgpoUzNzNjcxOURWNWQyQzI4MklseVB3QWlWNUZwRFhTUWRHVzBBcmd4NE1XdldDelg3ckk9 Cj16WG80Ci0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============8618546867852747870==--