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: <3wpydsib5maytq4m4ve4b7wfbfkxwzd5m6u5woqr43qr6mickk@gw4ww6vvgyo5>
Date: Wed, 23 Apr 2025 09:31:42 +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 Tue, Apr 22, 2025 at 05:21:31PM -0500, Theodore Ts'o wrote:
> On Wed, Apr 16, 2025 at 06:50:00PM +0200, Alejandro Colomar wrote:
> > 
> > I'm updating the manual pages for POSIX.1-2024.  One of the changes
> > in this revision is that POSIX now encourages implementations to
> > disallow using new-line characters in file names.
> > 
> > Historically, Linux (and maybe all existing POSIX systems?) has
> > allowed new-line characters in file names.
> 
> Do we have any information of which implementations (if any) might
> decide to disallow new-line characters?

Such a list doesn't exist.

<http://austingroupbugs.net/view.php?id=251>

> If the Austin Group is going to add these sorts of "encouragements"
> without engaging with us dirctly, it seems to be much like King Canute
> commanding that the tide not come in....
> 
> Personally, I'm not convinced a newline is any different from any
> number of weird-sh*t characters, such as zero-width space Unicode
> characters, ASCII ETX or EOF characters, etc.

Newline is slightly more problematic than those, especially in scripts.

But yes, other characters (mainly control characters) were also
discussed in that bug.  From what I can read, it seems they were scared
that if they attempted to suggest banning all control characters at
once, there might be more opposition, and the standard would be toilet
paper.

> I suppose we could add a new mount option which disallows the
> weird-sh*t characters, but I bet it will break some userspace
> programs,

That's an interesting approach.  Being an opt-in mount option, users
will only break at their will, and they can always go back to old mode
when they need to do some operation with weird-sh*t characters.

TBH, while I see the chances of breaking stuff (so I don't see this
being the default in a long time; maybe ever), I think an opt-in mode
would be interesting, for those that know that don't need to handle such
broken file names, to have a tighter system.  I would enable such a mode
in my systems.

> and it also begs the question of *which* weird-sh*t
> characters should be disallowed by the kernel.

I think a mode for disallowing _any control characters_ (aka [:cntrl:],
aka 0-31) would be a good choice.

> > I guess there's no intention to change that behavior.  But I should
> > ask.  I thought of adding this paragraph to all pages that create
> > file names:
> > 
> > 	+.SH CAVEATS
> > 	+POSIX.1-2024 encourages implementations to
> > 	+disallow creation of filenames containing new-line characters.
> > 	+Linux doesn't follow this,
> > 	+and allows using new-line characters.
> > 
> > Are there any comments?
> 
> I think this is giving the Austin Group way more attention/respect
> than they deserve, especially when it's an optional "encourage", but
> whatever...

I'm not worried about that, I was more worried about the churn in the
pages.  I later remembered we have a pathname(7) page, so I'll put it
there, just once.

Have a lovely day!
Alex

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

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