Feature #20971
open
I think that rb_path_check
is a separate thing from "object taintedness", and that the removal of path_tainted_p
in env_aset
in despite of it is in !OBJ_TAINTED
side was unintentionally.
@jeremyevans0 (Jeremy Evans) What do you think?
From looking at the history, rb_path_check
was originally used by rb_env path_tainted
, presumably to check whether the PATH environment variable was tainted, so as not to trust it. That may be why it is in the hash.h header instead of the file.h header, even though it makes no sense in the hash.h header.
rb_path_check
was used in MJIT, to check for unsafe header files, but that was the last usage I could see in CRuby. I'm guessing that is a reason it may not have been deprecated/removed when $SAFE/taint was deprecated/removed.
If we can do a gem codesearch for rb_path_check
, and nothing important comes up, I am in favor of deprecating and then removing it. I looked through the first 5 pages of GitHub results and nothing of note came up, other than the fact that TruffleRuby does not implement the function.
I mean this warning went away since 2.7, which should be unrelated to tainted-ness.
$ ruby2.6 -w -rtmpdir -e 'Dir.mktmpdir("", "/tmp") {|w| File.chmod(0777, w); ENV["PATH"] = w}'
-e:1: warning: Insecure world writable dir /tmp/20241220-14749-10itz6k in PATH, mode 040777
nobu (Nobuyoshi Nakada) wrote in #note-3:
I mean this warning went away since 2.7, which should be unrelated to tainted-ness.
I see what you mean. I would be OK with adding that warning back.
Interesting, I thought the removal of that warning was intentional, do other languages have similar warnings? I guess it doesn't matter if it already used to do that 🤷
- Status changed from Open to Assigned
- Assignee set to matz (Yukihiro Matsumoto)
I think it would be OK to remove that warning (and rb_patch_check
etc totally), if it is recognized officially.
@matz (Yukihiro Matsumoto) What do you think?
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0Like0Like0