--===============0682648709==
Content-Type: multipart/alternative;
boundary="=====================_390289406==.ALT"

--=====================_390289406==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 09:13 AM 7/11/2007, UDP-Jack Bluebird wrote:

>Is there a way to restrict multiple "." from inbound transfers using
>the PathDenyFilter directive? I would think it could be done, I just
>don't have much experience with regex's. I have to move files coming
>into my proftpd server to VMS, and OS that does not deal well with
>files that have multiple periods.


(The weekend, when work can get done.)

I'm not exactly sure I understand what you wanted, as I'm comparing
to VMS experiences years-old. I think what you are saying is that
VMS can only handle filename formats of filename plus extension,
where there is at most the one period separating the filename and
extension. A filename of foo.tgz is okay, but foo.tar.gz is not
okay. As I Google there seem to be other restrictions to consider,
but we can certainly reject filenames with more than one period.

If you want to reject all paths where a path component has more than
one period we can do this:
PathDenyFilter "[.][^./]*[.]"
That says that anywhere that one path part has at least two periods
we reject it. This will reject
foo.tar.gz foo.tar. .foo. temp.temp.temp/foo
but will accept
foo.tgz temp.temp/foo.tgz

If you instead want to be more specific, and scrutinize _only_ the
filename, the last component of the path, then we have to get more
specific in the regex. We have to concentrate on the ending of the
path. We can use this:
PathDenyFilter "(^|/)[^./]*[.][^./]*[.][^/]*$"
This will reject
foo.tar.gz foo..tgz
but will accept
foo.tgz temp.temp/foo.tgz temp.temp.temp/foo
This will also reject a relative path using "..", like
../other/foo.tgz
Probably we could get around that if needed, but the RE would be
unrecognizable. ;-)

I see in various web documents that there are some possible
mechanical translations from Unix to VMS filenames, and some might be
possible with TJ's mod_rewrite and RewriteRule's, but that'd get
really hairy quickly. Simply rejecting the filenames is probably best.


Some discussion of the REs:

"[.][^./]*[.]"
We want to 'see' when there is at least two periods within one path
component. The normal path separator is '/' so if we say don't match
'/' that is sufficient to be 'between' separators. Saying "[.]"
will match one period character. Saying "[^./]" in the middle will
match one character that is not either a period or a slash. But we
make that part optional, so that two consecutive periods will also
match the "[.]" to either side. So we have a period followed by zero
or more characters that are not periods or slashes followed by a period.

Note the use of "[.]" instead of "\\." Some people find the overuse
of backslash characters to lead to "leaning toothpick syndrome",
where there are too many slash characters in an RE to read it
easily. Lately people have advocated using a character class
construct to make it easier to read characters that would have to be
'escaped' with backslashes.

"(^|/)[^./]*[.][^./]*[.][^/]*$"
We've seen the middle part of this above, so here discuss only the
added parts. We want to match against the very last part of the
path, so we must anchor the matching to the end of the path using
'$'. Then we need to start matching at either beginning of the path
if there is nothing but the filename, or following the last '/'
separator in the path. That's pretty tricky, and only works because
everything following explicitly doesn't match another '/', thus the
mentioned '/' must be the last one in the path.


>Thanks,
>
>Jack Bluebird


--=====================_390289406==.ALT
Content-Type: text/html; charset="us-ascii"



At 09:13 AM 7/11/2007, UDP-Jack Bluebird wrote:


Is there a
way to restrict multiple "." from inbound transfers using the
PathDenyFilter directive? I would think it could be done, I just don't
have much experience with regex's. I have to move files coming into my
proftpd server to VMS, and OS that does not deal well with files that
have multiple periods.


(The weekend, when work can get done.)


I'm not exactly sure I understand what you wanted, as I'm comparing to
VMS experiences years-old.  I think what you are saying is that VMS
can only handle filename formats of filename plus extension, where there
is at most the one period separating the filename and extension.  A
filename of foo.tgz is okay, but foo.tar.gz is not okay.  As I
Google there seem to be other restrictions to consider, but we can
certainly reject filenames with more than one period.


If you want to reject all paths where a path component has more than one
period we can do this:

      PathDenyFilter 
"[.][^./]*[.]"

That says that anywhere that one path part has at least two periods
we reject it.  This will reject

    foo.tar.gz   
foo.tar.    .foo.   temp.temp.temp/foo

but will accept

    foo.tgz    
temp.temp/foo.tgz


If you instead want to be more specific, and scrutinize _only_ the
filename, the last component of the path, then we have to get more
specific in the regex.  We have to concentrate on the ending of the
path.  We can use this:

      PathDenyFilter 
"(^|/)[^./]*[.][^./]*[.][^/]*$"

This will reject

    foo.tar.gz     foo..tgz

but will accept

    foo.tgz    
temp.temp/foo.tgz    temp.temp.temp/foo

This will also reject a relative path using "..", like

    ../other/foo.tgz

Probably we could get around that if needed, but the RE would be
unrecognizable. ;-)


I see in various web documents that there are some possible mechanical
translations from Unix to VMS filenames, and some might be possible with
TJ's mod_rewrite and RewriteRule's, but that'd get really hairy
quickly.  Simply rejecting the filenames is probably best.




Some discussion of the REs:


  "[.][^./]*[.]"

We want to 'see' when there is at least two periods within one path
component.  The normal path separator is '/' so if we say don't
match '/' that is sufficient to be 'between' separators.  
Saying "[.]" will match one period character.  Saying
"[^./]" in the middle will match one character that is not
either a period or a slash.  But we make that part optional, so that
two consecutive periods will also match the "[.]" to either
side.  So we have a period followed by zero or more characters that
are not periods or slashes followed by a period.


Note the use of "[.]" instead of "\\."  
Some people find the overuse of backslash characters to lead to
"leaning toothpick syndrome", where there are too many slash
characters in an RE to read it easily.  Lately people have advocated
using a character class construct to make it easier to read characters
that would have to be 'escaped' with backslashes.


  "(^|/)[^./]*[.][^./]*[.][^/]*$"

We've seen the middle part of this above, so here discuss only the
added parts.  We want to match against the very last part of the
path, so we must anchor the matching to the end of the path using
'$'.  Then we need to start matching at either beginning of the path
if there is nothing but the filename, or following the last '/' separator
in the path.  That's pretty tricky, and only works because
everything following explicitly doesn't match another '/', thus the
mentioned '/' must be the last one in the path.  




Thanks,

 

Jack Bluebird



--=====================_390289406==.ALT--



--===============0682648709==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--===============0682648709==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ProFTPD Users List
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html
--===============0682648709==--