Bruce Momjian wrote: > Bruce Momjian wrote: > > Tom Lane wrote: > > > Bruce Momjian <br...@momjian.us> writes: > > > > Tom Lane wrote: > > > >> Bruce Momjian <br...@momjian.us> writes: > > > >>> I have reviewed is_absolute_path() and have implemented > > > >>> path_is_relative_and_below_cwd() to cleanly handle cases like 'E:abc' > > > >>> on > > > >>> Win32; patch attached. > > > >> > > > >> This patch appears to remove some security-critical restrictions. > > > >> Why did you delete the path_contains_parent_reference calls? > > > > > > > They are now in path_is_relative_and_below_cwd(), > > > > > > ... and thus not invoked in the absolute-path case. This is a security > > > hole. > > > > > > > I don't see a general reason to prevent > > > > ".." in absolute paths, only relative ones. > > > > > > load '/path/to/database/../../../path/to/anywhere' > > > > Ah, good point. I was thinking about someone using ".." in the part of > > the path that is compared to /data or /log, but using it after that > > would clearly be a security problem. > > > > I have attached an updated patch that restructures the code to be > > clearer and adds the needed checks. > > I decided that my convert_and_check_filename() usage was too intertwined > so I have developed a simplified version that is easier to understand; > patch attached.
Applied, with a new mention of why we don't use GetFullPathName(): + /* + * On Win32, a drive letter _not_ followed by a slash, e.g. 'E:abc', is + * relative to the cwd on that drive, or the drive's root directory + * if that drive has no cwd. Because the path itself cannot tell us + * which is the case, we have to assume the worst, i.e. that it is not + * below the cwd. We could use GetFullPathName() to find the full path + * but that could change if the current directory for the drive changes + * underneath us, so we just disallow it. + */ -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
