# New Ticket Created by Samantha McVey
# Please include the string: [perl #130904]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=130904 >
"A-B C".split([" ", "-"]) when it tries
to swap something going via the IB2 sub. It get
I have done some research on this issue. The "correct" behavior seems
to be to match what Windows would do in cmd.exe. That would provide
the users with the least surprise.
Michael Kaplan's guidance[1] on file names seems to also describe how
Windows handles names of environment variables:
> For
Timo Paulssen via RT wrote:
>Thankfully, \0 won't accept diacritics,
Ah, quite right. I forgot about that rule. The text segmentation
standard says that there's a grapheme cluster boundary before and after
every control character, except in the middle of a CR-LF sequence.
Hence a nul codepoint (
Brandon Allbery via RT wrote:
>It's also less than awesome that POSIX, at least, doesn't let you confirm
>that a filename is syntactically valid,
At the syscall interface it's very simple: any sequence of non-nul octets
may be used as a pathname. Since the pathname is passed in nul-delimited
form
On Thu, Mar 2, 2017 at 9:14 AM, Joachim Durchholz wrote:
> For the other invalid characters, the error will (well: should) be caught
> by the filesystem.
> Trying to check that in advance is a security hole in waiting - somebody
> might mount or unmount filesystems between check and use.
>
This,
On 02.03.2017 14:56, Brandon Allbery wrote:
- any character disallowed by specific filesystems (consider CIFS)
Wouldn't these characters be caught by the file system (whichever that is)?
It would be pretty hard to do a reliable validation as soon as mounted
filesystems come into play.
Amon
On Thu, Mar 2, 2017 at 8:56 AM, Brandon Allbery wrote:
> - the sequence `//` which is specifically undefined by POSIX
In the interests of heading off incoming pedanticness, possibly to "defend"
the indefensible: this is only undefined as a prefix. It is an error as an
infix.
--
brandon s all
To be clear: the POSIX spec does, specifically, disallow NUL. *Only* NUL.
Which then leaves:
- any character disallowed by specific filesystems (consider CIFS)
- the sequence `//` which is specifically undefined by POSIX
Among others. Is it correct to disallow NUL and thereby have a special case
FWIW, this bug makes at least mild exploitation possible, depending on how the
program validates input:
Setup: dir and input check to ensure user-supplied path is not outside of it:
13:41 IOninja m: "/tmp/root/tmp".IO.mkdir;
"/tmp/root/secret.txt".IO.spurt: 'p4sswrd';
13:41
On Thu, Mar 2, 2017 at 5:29 AM, Zefram wrote:
> It is less than awesome that
> Perl 6 accepts "foo\x[0]bar" as a pathname, when it doesn't resemble
> any pathname valid on the OS
>
It's also less than awesome that POSIX, at least, doesn't let you confirm
that a filename is syntactically valid, e
# New Ticket Created by Zefram
# Please include the string: [perl #130900]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=130900 >
> spurt("foo\x[0]bar", "wibble")
True
The above writes to a file named "foo". It is less than
11 matches
Mail list logo
