Re: Re: Filepath validation and untainting

. . . 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.

Comment on Re: Re: Filepath validation and untainting

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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...

fruiture

[reply]