linux-kernel - Re: newlines in filenames; POSIX.1-2024

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <xv6zdpdkni6562xmkmspvydncwez25jppsh7gfo64ngm2jkgjh@isyqz2jz3l2i>
Date: Thu, 24 Apr 2025 09:00:00 +0200
From: Alejandro Colomar <alx@...nel.org>
To: Theodore Ts'o <tytso@....edu>
Cc: linux-kernel@...r.kernel.org, linux-api@...r.kernel.org, 
	linux-man@...r.kernel.org
Subject: Re: newlines in filenames; POSIX.1-2024

Hi Ted,

On Wed, Apr 23, 2025 at 07:05:34PM -0500, Theodore Ts'o wrote:
> On Wed, Apr 23, 2025 at 09:31:42AM +0200, Alejandro Colomar wrote:
> > 
> > <http://austingroupbugs.net/view.php?id=251>
> 
> Ugh.  Reading through that bug, despite the fact that the original
> proposal was *significantly* bared down, has greatly reduced my
> respect for the Austin Group.
> 
> One of the people in that bug argued unironically that using pipes
> should be deprecated.  i.e., that somehow "find . ... -print0 | xargs
> -0 ..." was a security problem.

Huh!  I hadn't read that part.

> <<Sigh>>
> 
> Other people pointed out that creating proscriptions that were not
> implemented by many/most historical implementations would fragment the
> standard and decrease the respect people would have towards the POSIX
> specification.  That was the "toilet paper" comment which you
> referenced.
> 
> Well, they got that right.
> 
> > I think a mode for disallowing _any control characters_ (aka
> > [:cntrl:], aka 0-31) would be a good choice.
> 
> As the Austin Group Bug pointed out, the problem is that the control
> characters can be printable characters, depending on the code page
> that you might be using.  The example that was given was cp437.
> 
> The problem is that historically speaking, the kernel does *not* know
> about what locale that is in use.  We made an exception to handle case
> folding, where we added Unicode tables into the kernel.  Some would
> say that was a major mistake, and it's certainly been a headache.

Hmmmm, I'm not too worried about that code page for my own system, and
most people aren't either.  I still believe it would be good to have the
option to forbid 0-31, and let those users who need access file systems
with such weird conventions continue using the default (that is, not
enabling the new mode).  I think ASCII has won the character wars;
especially in POSIX systems.


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)