From: Florian Weimer <fweimer@redhat.com>
To: Alejandro Colomar <alx@kernel.org>
Cc: Jason Yundt <jason@jasonyundt.email>, linux-man@vger.kernel.org
Subject: Re: [PATCH v5] man/man7/pathname.7: Add file documenting format of pathnames
Date: Mon, 20 Jan 2025 09:20:27 +0100 [thread overview]
Message-ID: <877c6pew1g.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <5ghdwxt5hnyyfyjomhon5xotz5lcvr6fkjemv56654b4qzeilg@2pjj6dm3twj3> (Alejandro Colomar's message of "Sun, 19 Jan 2025 16:24:50 +0100")
* Alejandro Colomar:
> Hi Jason, Florian,
>
> On Sun, Jan 19, 2025 at 08:17:46AM -0500, Jason Yundt wrote:
>> > It seems you're passing a non-terminated string, and thus it's producing
>> > a non-terminated string. Why don't you pass a null-terminated string?
>> >
>> > That is, inbytesleft should include be the length + 1.
>>
>> Here’re my concern: iconv(3) is going to see the final element of
>> utf32_pathname and interpret it as a U+0000 null character. In some
>> character encodings, U+0000 null is encoded as a single null byte. In
>> other character encodings, U+0000 null is encoded as something other
>> than a single null byte. For example, in Modified UTF-8, U+0000 null is
>> encoded as the bytes C0 80. Is there any guarantee that
>> nl_langinfo(CODESET) will return a character encoding where U+0000 is
>> represented as a single null byte?
> Florian, do you know this?
Character sets used by glibc locales must be mostly ASCII-transparent.
This includes the mapping of the null byte. It is possible to create
locales that do not follow these rules, but they tend to introduce
security vulnerabilities, particularly if shell metacharacters are
mapped differently.
Thanks,
Florian
next prev parent reply other threads:[~2025-01-20 8:20 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-13 21:32 [PATCH] man/man7/path-format.7: Add file documenting format of pathnames Jason Yundt
2025-01-14 0:20 ` Alejandro Colomar
2025-01-14 12:54 ` [PATCH v2] " Jason Yundt
2025-01-14 13:14 ` Alejandro Colomar
2025-01-14 21:00 ` Jason Yundt
2025-01-14 23:06 ` Alejandro Colomar
2025-01-15 16:21 ` Jason Yundt
2025-01-15 16:47 ` Alejandro Colomar
2025-01-15 17:44 ` G. Branden Robinson
2025-01-15 9:01 ` Florian Weimer
2025-01-14 21:01 ` [PATCH v3] man/man7/path_format.7: " Jason Yundt
2025-01-15 16:20 ` [PATCH v4] man/man7/pathname.7: " Jason Yundt
2025-01-15 17:12 ` Florian Weimer
2025-01-15 17:20 ` Alejandro Colomar
2025-01-15 18:37 ` A modest proposal regarding pathnames (was: " G. Branden Robinson
2025-01-15 19:25 ` Alejandro Colomar
2025-01-15 19:47 ` Alejandro Colomar
2025-01-17 13:02 ` [PATCH v5] " Jason Yundt
2025-01-17 14:14 ` Alejandro Colomar
2025-01-18 0:01 ` Jason Yundt
2025-01-18 0:23 ` Alejandro Colomar
2025-01-19 13:17 ` Jason Yundt
2025-01-19 15:24 ` Alejandro Colomar
2025-01-20 8:20 ` Florian Weimer [this message]
2025-01-20 11:14 ` Alejandro Colomar
2025-01-20 13:17 ` Jason Yundt
2025-01-20 13:25 ` Alejandro Colomar
2025-01-17 23:59 ` [PATCH v6] " Jason Yundt
2025-01-20 16:24 ` [PATCH v8] " Jason Yundt
2025-01-20 16:36 ` Alejandro Colomar
2025-01-20 19:06 ` [PATCH v9] " Jason Yundt
2025-01-20 22:26 ` Alejandro Colomar
2025-01-21 0:26 ` C code style for Linux man-pages examples (was: [PATCH v9] man/man7/pathname.7: Add file documenting format of pathnames) G. Branden Robinson
2025-01-21 1:05 ` Alejandro Colomar
2025-01-21 13:39 ` Jason Yundt
2025-01-21 14:00 ` Alejandro Colomar
2025-01-21 13:35 ` [PATCH v10] man/man7/pathname.7: Add file documenting format of pathnames Jason Yundt
2025-01-23 23:51 ` Alejandro Colomar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877c6pew1g.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=alx@kernel.org \
--cc=jason@jasonyundt.email \
--cc=linux-man@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox