From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTP id AEA165A0304 for ; Thu, 23 May 2024 16:24:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1716474268; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Db7PZjtFBv3oUSSQ441XYiMfz2lE7JFLogSO7kERWmQ=; b=Ovl4Vcn7TrbqlmhvKQ16Xti1KxRDCLiHD2SjAK/qZZNNcyPHC6j62JMGQ1WhyNFEshiXlf pZ0jhIpT32x8oGHyl9sIrzFmQZQCQtWmvfl6PhAozNpyMAniREVekaIV+WBudr0rPPQKNP XOvmuV8VGRpo0m/BXY7NEZY4NGpvZ08= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-322-ddvW25-ENUKmQmhmkOz1vg-1; Thu, 23 May 2024 10:24:26 -0400 X-MC-Unique: ddvW25-ENUKmQmhmkOz1vg-1 Received: by mail-ej1-f72.google.com with SMTP id a640c23a62f3a-a59efa9f108so129375466b.2 for ; Thu, 23 May 2024 07:24:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716474263; x=1717079063; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Db7PZjtFBv3oUSSQ441XYiMfz2lE7JFLogSO7kERWmQ=; b=STBjtqRq23gIobT94m73BlJzlI6A+oKOyDasLkosjWYZDUiJI3Cb90+tb8AaaWq/st VenK8/1aNbOMSGRVq7LMvyg9rM3Glrb6cqN2NKMmpg+k+CbMm7LpztItVPaigWMYMOJP tvNG0FYyGfUVg1Nzo8o8kIYryu2yYtCBwVX6LNQkMDNvQa/+AZ8t7RG9R1VQ/knngk16 sRzrkkB3MLA4r9pWdHY1iFFCKoAyjOMfCxej8/MbbEQhfwpQ1Rt8ottuX6S9+pWNkNxL oCtoxUvXHoBz1ubXSyu4RYYinSfkNlIna/8wBZUIfF318in47K7vEx26y8hRz6OWXpjM nJyg== X-Gm-Message-State: AOJu0Yw+JEInHVBqqQveAO2LHTjIGyuXavId40aWlKC8nLYcZWkOYGXn hko1D6Wgv34kj7hTLUcGD/urPgeeBzK+OIi28daTfgPWeNYPwWvNICEscDH6ODYMW/YKvaMwQSk 85ZG/dIqzTrrJ3ok1UusCSvMs4VMmGxSRsi5CHUyJn9ZlPhBlAw== X-Received: by 2002:a17:907:71d7:b0:a58:e2b1:92c2 with SMTP id a640c23a62f3a-a622816723cmr288541466b.57.1716474263566; Thu, 23 May 2024 07:24:23 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFB5QOv/a9KfmbN/oenF3D/khQf71QmJJ5SMk2/98klluAGcXRNAbcxmsHEKbm7r22yhUrK5w== X-Received: by 2002:a17:907:71d7:b0:a58:e2b1:92c2 with SMTP id a640c23a62f3a-a622816723cmr288539166b.57.1716474262899; Thu, 23 May 2024 07:24:22 -0700 (PDT) Received: from maya.cloud.tilaa.com (maya.cloud.tilaa.com. [164.138.29.33]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a5a17b17f37sm1941036266b.224.2024.05.23.07.24.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 May 2024 07:24:22 -0700 (PDT) Date: Thu, 23 May 2024 16:23:47 +0200 From: Stefano Brivio To: Danish Prakash Subject: Re: [PATCH] pasta.c: modify hostname when detaching new namespace Message-ID: <20240523162347.44e6faf3@elisabeth> In-Reply-To: References: <20240520083650.12032-1-contact@danishpraka.sh> <20240521193400.4f1b15c5@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.36; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: WL5RPHTXLEJM3BGIFIZ6JZ3HUVHWR7KO X-Message-ID-Hash: WL5RPHTXLEJM3BGIFIZ6JZ3HUVHWR7KO X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Danish, it would be easier if you answered inline. If Gmail is making it hard, perhaps switch to an email client (I use claws-mail)? Anyway, it's not a big issue for the moment: On Thu, 23 May 2024 19:22:16 +0530 Danish Prakash wrote: > Thanks for the review and the links. > > > + if (!gethostname(hostname + sizeof(HOSTNAME_PREFIX) - 1, HOST_NAME_MAX + 1 - sizeof(HOSTNAME_PREFIX))) { > > + if (sethostname(hostname, strlen(hostname))) > > + debug("Unable to set pasta-prefixed hostname"); > > } > > The above snippet, although it looks correct, Wait, I didn't suggest if (!gethostname(...)), I suggested gethostname(...). The ! there is yours. :) > doesn't work in cases where the hostname is long enough (~>58 chars). > It works fine for shorter hostnames. In any case, it depends on how you define "doesn't work". What should we do if the original hostname is long enough that we can't prefix "pasta-" while fitting in 63 characters? Append it anyway and truncate the original hostname (what my line did), or leave it like it is (what your snippet does, I guess)? It's a matter of taste I'd say. > The call to `gethostname()` sets errno to 36 > (ENAMETOOLONG). Upon looking further, it seems that even though the > manpage for `gethostname(char *name, size_t len)` states.. > > > If the null-terminated hostname is too large to fit, then the name is truncated, and no error is returned (but see NOTES below). ...then the NOTES section disappeared and this ended up in "ERRORS", in the Linux man-pages: ENAMETOOLONG (glibc gethostname()) len is smaller than the actual size. (Before glibc 2.1, glibc uses EINVAL for this case.) > ...It would still throw ENAMETOOLONG if the value of len is smaller > than `strlen(hostname)+1` (referring to the snippet below). I'm not > sure if I'm missing out on an edge case while calculating the > boundaries here because the `memcpy` call is certainly truncating the > hostname[1] before ending up returning ENAMETOOLONG, which seems > conflicting[1]: ...no, I don't think you're missing out on any edge case, you simply missed that part of the man page. Note that we need to play nicely with other C libraries too (especially musl), so error or not, we should do the right/same thing. Perhaps most robust approach: if (!gethostname(hostname + sizeof(HOSTNAME_PREFIX) - 1, HOST_NAME_MAX + 1 - sizeof(HOSTNAME_PREFIX)) || errno == ENAMETOOLONG) { so that if it's glibc, and it truncates, we'll just go ahead with our truncated name, but not if there's any other error. Note that you don't strictly need the NULL byte at the end, see sethostname(2) -- just make sure you don't print it or anything like that. -- Stefano