Repository navigation
0.6.2: okrun opens a relative image name that climbs (..) - #38
Merged
Merged
Conversation
A relative name was passed to the file system as it stood, and an openkal name admits no `..' component, so okrun refused an image named above the working directory (`../image.oke'; `./image.oke' and an absolute name opened). The runner folds a relative name against the first directory's name --- `..' and `.' lexically, a symlink left to the file system --- into the absolute name beneath it, then matches it against the supplied directories' names exactly as an absolute one is matched. A name that climbs past the root of the tree, or one beneath no directory, names nothing, as before. Every member is 0.6.2.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A relative image name that climbs --
../image, from a working directory below the one holding it -- failed withcannot be openedon every system, while the same name spelled absolutely or relative without ascent opened. The cause is a seam between two rules, not a defect in either: the fs interface accepts no name whose components ascend (a capability constraint its conformance suite states), and okrun's own lookup stripped only a leading./prefix before handing the name over, so..reached the interface unchanged.The fix folds a relative name lexically against the absolute name of the working directory's preopen and then runs the same longest-prefix match an absolute name takes; symlinks stay unresolved exactly as before, and a name that climbs past the namespace root keeps the existing error path. The fs rule itself is untouched.
run/src/run.cpp: the relative branch of the lookup foldsseg/..and.before prefix matchingci.yml: the run job's regression step executes an image through../../from a directory two levels below itMeasured before: the failing form returns 127 with
okrun: ../x.oke cannot be opened. After: the same invocation runs the image, and./x, nested../../x, absolute and plain relative names keep their behaviour; a climbing name that escapes every preopen still reports cannot-be-opened.