New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nul in pathname #6117
Comments
From zefram@fysh.org
The above writes to a file named "foo". It is less than awesome that
This *is* an outright bug. If the string containing a nul is to be Watch out for "\x[0]\x[308]" when trying to detect nuls. -zefram |
From @timoOn Thu, 02 Mar 2017 02:29:27 -0800, zefram@fysh.org wrote:
Thankfully, \0 won't accept diacritics, though i'd have to look at the NFG algo to see if that's valid for every diacritic in unicode, or just some subset. |
The RT System itself - Status changed from 'new' to 'open' |
From @geekosaurOn Thu, Mar 2, 2017 at 5:29 AM, Zefram <perl6-bugs-followup@perl.org> wrote:
It's also less than awesome that POSIX, at least, doesn't let you confirm -- |
From @zoffixznetFWIW, 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: Detection is triggered when `..` is supplied as the path: But fails when we follow it with a nul byte, causing display of contents of parent directory: |
From @geekosaurTo be clear: the POSIX spec does, specifically, disallow NUL. *Only* NUL. Which then leaves: - any character disallowed by specific filesystems (consider CIFS) Among others. Is it correct to disallow NUL and thereby have a special case -- |
From @geekosaurOn Thu, Mar 2, 2017 at 8:56 AM, Brandon Allbery <allbery.b@gmail.com> wrote:
In the interests of heading off incoming pedanticness, possibly to "defend" -- |
From @toolforgerOn 02.03.2017 14:56, Brandon Allbery wrote:
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
Yes. For the other invalid characters, the error will (well: should) be |
From @geekosaurOn Thu, Mar 2, 2017 at 9:14 AM, Joachim Durchholz <jo@durchholz.org> wrote:
This, sadly, is not always true. The // prefix is a specific case in point. -- |
From zefram@fysh.orgBrandon Allbery via RT wrote:
At the syscall interface it's very simple: any sequence of non-nul octets Perl 6 doesn't need to know about those rules that are enforced by the -zefram |
From zefram@fysh.orgTimo Paulssen via RT wrote:
Ah, quite right. I forgot about that rule. The text segmentation -zefram |
From @zoffixznetOn Thu, 02 Mar 2017 02:29:27 -0800, zefram@fysh.org wrote:
Thank you for the report. This is now fixed in high-level IO routines and clases: Fix: rakudo/rakudo@e6814986c0 For the case of $*SPEC.splitpath: it's a low-level routine that most users won't - IO grant |
@zoffixznet - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#130900 (status was 'resolved')
Searchable as RT130900$
The text was updated successfully, but these errors were encountered: