Bug #15417
closedPathname case insensitive comparison
Description
While fixing some issues with Pathname, I noticed the following comparison:
SAME_PATHS = if File::FNM_SYSCASE.nonzero?
# Avoid #zero? here because #casecmp can return nil.
proc {|a, b| a.casecmp(b) == 0}
else
proc {|a, b| a == b}
end
Firstly, this seems wrong to me because case sensitivity is per-mount not a global state for the entire system.
Secondly, it concerns me because sometimes this becomes security bug, e.g. path may or may not be the same, and could slip through some sanity check (e.g. git could checkout files to .git
directory with case insensitive file system).
Unless string match exactly, we should leave it to file system to determine if the path is equivalent or not (e.g. in the case of Pathname#relative_path_from
). Trying to be too clever might cause future pain.
Updated by jeremyevans0 (Jeremy Evans) almost 4 years ago
ioquatix (Samuel Williams) wrote:
Unless string match exactly, we should leave it to file system to determine if the path is equivalent or not (e.g. in the case of
Pathname#relative_path_from
). Trying to be too clever might cause future pain.
I agree. I think for maximum compatibility, we should only use a file system check if the paths do not match but differ only in case. I have added a pull request that implements that: https://github.com/ruby/ruby/pull/3490
Updated by nobu (Nobuyoshi Nakada) almost 4 years ago
The arguments are path components but not paths, can't stat.
Updated by jeremyevans0 (Jeremy Evans) almost 4 years ago
I don't think this is fixable. SAME_PATHS is only used in relative_path_from
, which is explicitly documented to not access the filesystem. I'll update the documentation for relative_path_from
to explain the issue.
Updated by jeremyevans (Jeremy Evans) almost 4 years ago
- Status changed from Open to Closed
Applied in changeset git|cc5b7ed1dccc6a5cffa5c52778c6db8794722404.
Document limitation of Pathname#relative_path_from [ci skip]
This method is explicitly documented to not access the filesystem,
and the only way to get the correct behavior for a case where the
filesystem's case sensitivity differs from the operating system
default would be to access the filesystem.
Fixes [Bug #15417]