At 03:40 PM 3/29/2002, martin f krafft wrote: > ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../* ... > DenyFilter \*.*/ Just as a quick question, why not deny the string "/../" (you may have to deny the regex "/\.\./", depending how the filter in question works)? As far as I can tell, it's the ability to embed "/../" into a path that is at the root of this, far more than the ability to embed wildcards. I can't think of a situation in which "/../" should appear in a user-supplied path, except after a string of repeated "../"s. The workaround suggested by Mr Krafft would disable some useful functionality - one large user of mine, for instance, was keen to have my own software evaluate wildcards in the body of the path, which Mr Krafft's workaround disables completely. They even paid for the privilege (not enough, but they paid ;-)) So, let's see, a regex that would deny "/../", except as part of a string of such... One bash would be "[^/.].*/\.\./" - matching "/../" if it's after any character other than '/' or '.'. Doubtless someone can come up with something better. Alun. ~~~~ -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at 1602 Harvest Moon Place | http://www.wftpd.com or email alunat_private Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT.
This archive was generated by hypermail 2b30 : Wed Apr 03 2002 - 22:00:39 PST