Re: Filepath validation and untainting

I don't know if there's another module to do that. I don't think it makes much sense, because by using a filetest-operator like -e I can without any danger ensure a file exists (is a file,a directory) and that includes that the path that is tested is a valid path for whatever OS I'm on, otherwise it could not point to a file.

Your regexp does in fact only check for character occurences, because everything is marked as optional via *,? (the ()+ expression only contains optional ones), so you can have '//////','XXXXXXXXXX','///ABC//DEF//', which can all be valid as path in the end. So you're better off by just using tr{/\\a-zA-Z0-9.-}{}c in order to validate no unwanted characters are found, that hase the same effect at much less work for the computer. And this singel limitation is alreade inaccurate, because a good OS allows more than these characters in filenames.

--
http://fruiture.de

Comment on Re: Filepath validation and untainting

Replies are listed 'Best First'.
Re: Re: Filepath validation and untainting by hardburn (Abbot) on Feb 12, 2003 at 17:01 UTC
. . . by using a filetest-operator like -e I can without any danger ensure a file exists (is a file,a directory) and that includes that the path that is tested is a valid path for whatever OS I'm on, otherwise it could not point to a file. I'd like to check for files that may not exist yet, or might be on a completely different OS. -e just won't cut it. So you're better off by just using tr{/\\a-zA-Z0-9.-}{}c in order to validate no unwanted characters are found, that hase the same effect at much less work for the computer. The data being returned has to be untainted. tr/// won't do that. ---- Invent a rounder wheel.	[reply]
Re: Re: Re: Filepath validation and untainting by fruiture (Curate) on Feb 12, 2003 at 18:14 UTC
So, what's actually an syntactically impossible path? Can you say much more than what a tr/// check says? (Untainting can be done with a fake-regexp like /(.*)/, you don't need something complicated for that.) What can you really exclude? Not much Apart from /\.\.\.+/, or? Bit still I can't see the sense of that, why do you want to check whether a filename is syntactically possible. It doesn't give you any hints about the actual possibility of creating or finding such a file... -- http://fruiture.de	[reply]