Searching for a cue.mod
directory reaches all the way up to /
#2200
Unanswered
jpluscplusm
asked this question in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The loop that looks for a
cue.mod
directory can iterate its way up to the top of the executing machine's filesystem hierarchy (/
), and will do so every time thecue
CLI is invoked with a sub-command that needs to work out if it's there's a module root dir present or not, but such a directory doesn't exist. The code is here: https://github.com/cue-lang/cue/blob/master/cue/load/config.go#L594This feels slightly whiffy. The CLI will be examining and trusting directories that aren't necessarily under the control of the executing user. The eventual result of a CUE evaluation can be affected by files outside the user's control.
This kind of behaviour came to light and bit
git
in CVE-2022-24765 (https://github.blog/2022-04-12-git-security-vulnerability-announced/), and although that CVE also chains together arbitrary command execution, it feels like acknowledging and validating this behaviour would be the right thing for CUE to do. Just /perhaps/ there's a language-/module-spec-affecting aspect, too ...I don't /think/ there's a security concern here (yet), but it feels like putting a constraint/halting-condition on the FS iteration loop that's more than the current "did we find a cue.mod dir?" or "did we reach
/
?" is a sensible thing to do earlier rather than later. If only so that ecosystem customs don't build up that will be affected by breaking changes in the future.Git's response to CVE-2022-24765 was to default to stopping their config search directory traversal when the directory ownership changed. They also have config settings (via environment variables, given that the behaviours being controlled are relevant /during/ the search for a config file, hence these can't be controlled /inside/ config files) that dictate directories not to traverse through, both for security and network-filesystem-performance reasons; and a setting not to cross filesystem boundaries. These aren't suggestions for CUE, but observations of the kind of controls that a directly-affected project has found relevant.
I'm really interested in folks' thoughts. Am I being paranoid, here? /Too/ paranoid?
Beta Was this translation helpful? Give feedback.
All reactions