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 <passt-dev@passt.top>; 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 <passt-dev@passt.top>; 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 <sbrivio@redhat.com>
To: Danish Prakash <contact@danishpraka.sh>
Subject: Re: [PATCH] pasta.c: modify hostname when detaching new namespace
Message-ID: <20240523162347.44e6faf3@elisabeth>
In-Reply-To: <CAA5kkEAgGgGyD0yFuTAEcmCURFygsebAgSba-WBxxStizUkNcg@mail.gmail.com>
References: <20240520083650.12032-1-contact@danishpraka.sh>
<20240521193400.4f1b15c5@elisabeth>
<CAA5kkEAgGgGyD0yFuTAEcmCURFygsebAgSba-WBxxStizUkNcg@mail.gmail.com>
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 <passt-dev.passt.top>
Archived-At: <https://archives.passt.top/passt-dev/20240523162347.44e6faf3@elisabeth/>
Archived-At: <https://passt.top/hyperkitty/list/passt-dev@passt.top/message/WL5RPHTXLEJM3BGIFIZ6JZ3HUVHWR7KO/>
List-Archive: <https://archives.passt.top/passt-dev/>
List-Archive: <https://passt.top/hyperkitty/list/passt-dev@passt.top/>
List-Help: <mailto:passt-dev-request@passt.top?subject=help>
List-Owner: <mailto:passt-dev-owner@passt.top>
List-Post: <mailto:passt-dev@passt.top>
List-Subscribe: <mailto:passt-dev-join@passt.top>
List-Unsubscribe: <mailto:passt-dev-leave@passt.top>
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 <contact@danishpraka.sh> 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