| Re: [chrony-dev] chrony 3.5.1 and PATH_MAX |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
- To: chrony-dev@xxxxxxxxxxxxxxxxxxxx
- Subject: Re: [chrony-dev] chrony 3.5.1 and PATH_MAX
- From: Miroslav Lichvar <mlichvar@xxxxxxxxxx>
- Date: Mon, 24 Aug 2020 09:16:41 +0200
- Authentication-results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlichvar@xxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1598253410; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aATLwDGsyfW2GF6dI7Wp24b2fhfr8ejKrrJSuSDzy7o=; b=PfdOWqwQIeEgv0X7j20dunGzDd2T1ksAMBJxZ/mIA0MDRv6qa+kwgiOgnxlKxme6M4eKBC Ei0meO0v0UdYG4PNjWkUviXXKnJFrXaAxZNc5CD8Tf1ACMkUc4cUFjQYikoYiO3wWyZrdw 6uAVW3LYcGWb1Yl0Zzh/J8yj5b3KU/0=
On Sat, Aug 22, 2020 at 12:19:58PM +0200, Matthias Andree wrote:
> Greetings,
>
> being the FreeBSD packager of chrony, I have recently become aware of
> the 3.5.1 security fix release, and reviewed the change.
Thanks for the review.
> Looking at
> <https://git.tuxfamily.org/chrony/chrony.git/commit/?h=3.5-stable&id=f00fed20092b6a42283f29c6ee1f58244d74b545>,
> I see that it is using char foo[PATH_MAX] - note that PATH_MAX is the
> maximum path length for a path *COMPONENT* so strictly speaking
> join_path() into some buffer that is PATH_MAX large can fail.
That's understood and it's noted in the original commit. PATH_MAX is
just a constant chosen to unify the lengths of all buffers that hold a
path in the chrony code and join_path() is supposed to return zero if
the joined path is too long.
> Note also that some systems (GNU Hurd) do NOT define PATH_MAX at all. So
> a join_path that uses a realloc() loop with exponential but bounded
> growth, and starts maybe at 256 bytes a buffer size, might be a more
> portable approach.
If PATH_MAX was missing on some supported OS, I'd probably define a
different constant and avoid unnecessary (re)allocations.
> Having said that, I don't currently foresee issues with supported
> FreeBSD versions. We have a PATH_MAX that should fit chrony's bill.
Great.
> I've learned some lessons between fetchmail 6.4.0-rc4 and fetchmail
> 6.4.5 in particular (repo available on Gitlab) and concluded to exclude
> some corner cases explicitly, in fetchmail.
Not supporting systems that don't have PATH_MAX? I see in the log an
issue with realpath(). I'm not sure if chronyd ever used a system
function that had an assumption about output buffer like that.
--
Miroslav Lichvar
--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.