Ftp-WG: Potentially unsound use of MDTM

Hi All,

can we make FTP session to continue when the lower layers goes for a while
and comes up again?. I guess this functionality should be given in the
session layer. Please provide me more information on this.

Regards
AThresh

-----Original Message-----
From: ftp-wg-owner [mailto:[email protected]]On Behalf Of David
Somers
Sent: Monday, July 15, 2002 5:28 PM
To: FTPEXT Working Group
Subject: Ftp-WG: Potentially unsound use of MDTM


Hi Alun,

Disclaimer: I'm new to the FTPEXT list, so firstly hello to all, and
secondly apologies if what I'm saying had been thrashed out before and I'm
regurgitating and/or talking horse manure.

> I'm receiving reports from some of my users that some FTP clients (and
> presumably FTP servers also?) attempt to use the MDTM command not just to
> display a file's time, but to _modify_ it.
>
> The format used is the sadly ambiguous "MDTM yyyymmddhhmmss[.fraction]
> filename".

When doing some ad-hoc research, I came across this too... RhinoSoft's
Serv-U appears to implement MDTM in this manner...RhinoSoft's FTP Voyager
client appears to use MDTM in this manner when it either detects that the
server is Serv-U (from the 220 mark), or from MDTM being in the FEAT
response.

> Since file names can have spaces, and may start with digits, there's a
> possibility of overlap, wherein it is not possible to say whether the
> command received is to set the time on one file, or display the time for
> another.  Granted, this confusion would require that a file
> "yyyymmddhhmmss
> xyz" exists in the same folder as one called "xyz", but I think
> that's not
> sufficiently unlikely for me to feel comfortable with implementing this
> extension to the FTP protocol.

I'm developing my own FTP server, and the logic I thought up to cope with
this situation was:

When you get MDTM, if the rest of the line corresponds *exactly* to a
filename (spaces and all!), assume MDTM <filename> and return the
modification time for the filename.

Otherwise, check that the first part of the line represents a valid
timestamp, and if so, process as MDTM <timestamp> <filename>.

(Yes, this is a bad hack. I don't like it either!)

> What are your feelings on this?  Am I being too anal-retentive?

Nah. Its an abuse of the MDTM command, and really should have been done as
an X-prefixed command.

> Is there a
> need for an FTP command to set the modification time on a file
> (presumably
> so as to allow files to be uploaded with their original
> modification dates,
> but perhaps for other reasons)?

I think that there is more than just the file modification time to consider.
For example, when mirroring files between servers, the creation time also
needs to be duplicated (if the underlying file system supports creation
times).

I think there are two ways this can be done.

1. Changing the non-standardized
      "MdTm" time-val SP pathname CRLF
   to something like
      "MFMT" time-val SP pathname CRLF
   where MFMT means Modify File Modification Time

   and also supporting a new command
      "MFCT" time-val SP pathname CRLF
   where MFCT means Modify File Creation Time

2. By extending the STOR command so that these additional parameters can be
specified. This will be useful for situations where a client can send a file
to a server, but can not see or modify the file (and its attributes)
afterwards... and it also means you can transfer a file and set its
attributes using one command instead of several (as in #1 above).

   So, how about something like:
   stox          = "STOX" [ stox-facts ] SP filename CRLF
   stox-facts    = 1*( stox-fact ";" )
   stox-fact     = stox-factname "=" time-val / stox-localfact / stox-osfact
   stox-factname = "CreateTime" / "ModifyTime"
   stox-localfact= "X." token
   stox-osfact   = <IANA assigned OS name> "." token

   where STOX means STORE EXTENDED

   This acts like "STOR", but additionally and optionally allows attributes
(create time, modification time and os/locally-defined ones) to be
specified.

   Notes
   =====
   1. filename is UTF-8 encoded.
   2. time-val is in UTC.
   3. If the creation time is not specified, it should be set to the current
date/time
   4. If the modification time is not specified, it should be set to the
creation date/time.
   5. Instead of doing a subsequent SITE CHMOD, this could used instead to
twiddle the appropriate bits.

   Examples
   ========

   Example 1: Store the file fred.txt. This behaves identically to having
issued "STOR fred.txt".

   C> STOX fred.txt
   S> 150 Opening ASCII data channel for fred.txt

   Example 2: Store the file fred.txt and set its creation time to Jan 1,
1970 23:59, and its modification time to Sep 8, 2001 11:12.

   C> STOX CreateTime=197010102359;ModifyTime=200109081112; fred.txt
   S> 150 Opening ASCII data channel for fred.txt

   FEAT response for STOX
   ======================

   If this command is supported, then there must be a FEAT response:

   stox-feat = SP "STOX" [SP stox-factlist] CRLF
   factlist = 1*( factname ";" )

   Example

   C> feat
   S> 211- <any descriptive text>
   S>  ...
   S>  STOX ModifyTime;Perm;X.WinSIS
   S>  ...
   S> 211 End

> [One or two of my potential
> users seem to
> think so, at least]  Is it worth proposing a more standardised, and
> unambiguous, command sequence, to forestall this possibly causing
> problems
> in future?  While I can't see any means to use this ambiguity as
> an attack,
> I do find that many sources of error come from different handlings of
> ambiguously stated 'standards'.

This is why standards must be unambiguous.

And finally, and completely unrelated to the above, does anybody know of any
clients that support the MLSx commands?

Cheers,

David Somers
Trevezel Systems GmbH (www.trevezel.com)

**************************Disclaimer**************************************************    
 
 Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' 
and 'confidential' and intended for use only by the individual or entity to which it is 
addressed. You are notified that any use, copying or dissemination of the information 
contained in the E-MAIL in any manner whatsoever is strictly prohibited.

****************************************************************************************