Subject: Ftp-WG: Potentially unsound use of MDTM

From: Alun Jones <[email-masked]>
Date: Fri, 12 Jul 2002 14:41:15 -0500

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

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.

What are your feelings on this?  Am I being too anal-retentive?  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)?  [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'.

Alun.
~~~~
--
Texas Imperial Software   | Try WFTPD, the Windows FTP Server. Find us at
1602 Harvest Moon Place   | http://www.wftpd.com or email [email-masked]
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.

---

From: Robert Elz <[email-masked]>
Date: Sun, 14 Jul 2002 11:35:11 -0500

This "feature" of some clients was known back when the MDTM test
in the mlst draft was being written - that's the point of one of
the examples showing a space in a file name with the part before
the space looking very much like a time ...

So, no, you certainly should not be implementing that broken
behaviour.

On the other hand, creating a new command to do this would certainly
be possible - no-one so far has been sufficiently motivated to
do the work.

kre

---

From: "David Somers" <[email-masked]>
Date: Mon, 15 Jul 2002 06:57:35 -0500

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.

> The format used is the sadly ambiguous "MDTM yyyymmddhhmmss[.fraction]

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.

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

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)

---

From: Robert Elz <[email-masked]>
Date: Mon, 15 Jul 2002 07:41:49 -0500

Date:        Mon, 15 Jul 2002 06:57:35 -0500
    From:        "David Somers" <[email-masked]>
    Message-ID:  <[email-masked]>

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

I don't know if you'd call it support or not, but I have an (unreleasable,
the code is too disguisting) client that can use the things.   But it is
very much a command line client - it only works in combination with a
human, so while it can parse MLSD and display  the output in a "prettier"
form than it comes down the wire, that's the end of its intelligence.

I can't imagine it would be all that hard (the parsing is trivial) to
make one of the clients that actually uses the values of listings
(for GUI interfaces, mirroring, building HTML out of ftp listings, etc)
couldn't be made to work at least as well with what comes from MLSD as
what comes from LIST.

kre

---

From: "Athresh Kumar .B.S" <[email-masked]>
Date: Mon, 15 Jul 2002 23:57:18 -0500

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-masked]]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,

   Notes
   =====

   Examples
   ========

   C> STOX fred.txt

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

   Example

   C> feat

Cheers,

David Somers

---

From: Alun Jones <[email-masked]>
Date: Tue, 16 Jul 2002 06:04:15 -0500

>session layer. Please provide me more information on this.

It already does this.  TCP/IP connections don't break when the layer 2 link 
is broken - your application, client or server, might decide to time out if 
there's been no activity for a while (usually around five minutes or so), 
but TCP/IP won't disconnect you.

Unless, that is, you're on Windows, where the Microsoft TCP/IP stack has 
chosen to act on "Media Sense", and will terminate all TCP/IP connections 
on a NIC when the cable is detected to be missing.  On all other operating 
systems (and non-default Windows systems), if you kick a cable loose, and 
re-plug it, your session will continue.

Alun.
~~~~

---

From: Sergey Ayukov <[email-masked]>
Date: Thu, 18 Jul 2002 12:07:25 -0500

> be possible - no-one so far has been sufficiently motivated to

ncftp/ncftpd allow to modify file dates on server via 'SITE UTIME'
command, and I have followed this approach in NFTP. Syntax looks like
'SITE UTIME filename YYYYMMDDhhmmss YYYYMMDDhhmmss YYYYMMDDhhmmss UTC'
where three times correspond to Unix-like 'access, modification, status
change' times.

-- 
Dr. Sergey Ayukov       | NFTP:   Spell differently. Work faster.
http://www.ayukov.com   |
mailto:[email-masked]   | runs on:  BeOS * OS/2 * Unix * Windows

---

From: Sergey Ayukov <[email-masked]>
Date: Thu, 18 Jul 2002 12:11:40 -0500

> clients that support the MLSx commands?

Later versions of NFTP (since December 1999) support MLST to some extent
but it is not enabled by default, you have to set 'try-FTP-extensions=yes'
in options file.  Contact me if you need more information.