On Thu, Jul 12, 2007 at 07:26:23PM +0200, Stefan Reinauer wrote:
Rather check the path before mkdir()ing.
Exactly the idea.
Maybe I should explain mkdirp_below() a bit more.
It parses the new path one subdir at a time (as separated by / or ) and calls realpath() to resolve it into an absolute path.
If realpath() fails for some other reason than the path not existing, return an error.
If the resolved absolute path is outside the specified parent directory, also return an error.
Otherwise, the new dir is created (no error if it already exists) and iterate to the next subdir.
Since realpath() only works with existing paths, only one dir can be checked at a time. This means subdir/../subdir will be considered to be outside subdir because subdir/.. in the second iteration tests false.
The only way to properly handle this is to do full path resolution per path_resolution(2) but that is too big of a wheel to re-invent.
subdir/.. constructs could be removed, but symlinks must also be checked then.
Great. Instead of calling mkdirp with ".", can we assume "." is always the starting point? (I think it is not called differently at any other point)
It's not, but it might be with a new -C option? Or should that call chdir() before extracting any files? I generally avoid chdir() since all of a sudden something needs to be done back in the startup working directory.
Simpler to chdir() and use ready-made paths (if they're relative) than to copy stuff around to create "relocated" paths though.
Maybe I'm too strict?
//Peter