Bug #15417: Pathname case insensitive comparison

• Status: Closed
• Assignee: -
• Target version: -
• Backport: 2.4: UNKNOWN, 2.5: UNKNOWN
• Tags: ext

[ioquatix (Samuel Williams)]

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.

[jeremyevans0 (Jeremy Evans)]

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

[nobu (Nobuyoshi Nakada)]

The arguments are path components but not paths, can't stat.

[jeremyevans0 (Jeremy Evans)]

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.

• 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]