Ftp-WG: RE: MFXX questions

> > 1. mlst-16 states that the MDTM command is only defined on files, not on
> > non-files like directories.  What about MFMT and MFF?  Sometimes
> > the draft
> > mentions "file" and sometimes "object in the NVFS", see e.g. section 4.1.
>
>OK. In my document (draft-somers-ftp-mfxx) that's an editorial mistake... it
>should only refer to objects... files and directories are just types of
>objects and they should be treated the same. Hopefully I'll get it right for
>draft -02 :-)

So it would be possible to set the modification time of a directory with 
MFMT but not to query it with MDTM because MDTM excludes directories?

> > 2. Your draft shows (allows?) only the modification of the
> > traditional UNIX
> > mode bits, what about the sticky-bit set?
>
>Let's be clear about this: draft-somers-ftp-mfxx only specifies two facts
>for use in MFF, 'Create' and 'Modify'. Any others mentioned are purely
>examples of what could be possible - not what is possible - see section
>5.2.1.

Well, now that you mention it, yes your draft doesn't deal with UNIX modes 
(just as side-note: setting sticky-bits is possible for normal users).


> >
> > 3. I can imagine situations where I don't want remote users to set the
> > file's execution bit for uploaded files, even if changing permissions in
> > general is allowed.  Such a server receives then a "MFF UNIX.mode=775
> > some.file" which is not allowed or, depending on the point of view, not
> > supported.
>
>If not supported, then UNIX.mode shouldn't have been returned as part of the
>MFF FEAT response.
>
>If the client-PI sends it and the server-PI doesn't support it, 504 MUST be
>returned.

This example was perhaps not exact enough.  I'm talking of an FTP-server 
running on a UNIX box, being able to modify file mode bits.  But the 
administrator decides for some reasons that he does not like remote FTP 
clients to set the x-bit of files, anything else, like e.g. 666, is ok for 
files, but not setting any x-bit as in 775, even if the user owns the file 
and has all the permissions he or she needs to do it (the same chmod would 
succeed if the user would be logged in local with a shell).


> > It can now be argued that
> >
> >    (A) the client's permissions are not enough for the operation which
> > results in "550 no access",
> >
> >    (B) the MFF command is not implemented for this particular argument:
> > "504 not implemented for this parameter".
> >
> > On the other hand, the "no-x-bit" configuration could be seen as
> > some kind
> > of "missing granularity" (as it could happen for timestamps) which whould
> > then return a
> >
> >    (C) "213 UNIX.mode=664 some.file"
> >
> > showing the client the file's real mode after the operation.
>
>Good point. I think A or C would be the ideal response; B to me seems wrong.

If the server would deny, I think 504 is more exact, because it's not 
really a permission thing but a set x-bit in the parameter.

But anyway, I prefer variant C.  Why?  In the no-x-bit server setup the 
server's "permission granularity" is artificially degraded by the admin 
while modifying UNIX permissions in general is allowed (that's why the 
server offers UNIX.mode in it's FEAT response).

>...
> >
> >     Even if the client receives a 213 response it MUST|SHOULD parse
> >     the return value given in the response to see if this is (or
> >     comes near to) what the client wants.
>
>That is implicit in the current draft... it says the response MAY not be the
>same as that in the request. I'll add a note to implementors that they are
>RECOMMENED to parse 213 to see what was actually set.

To be more precise, I suggest that the client parses the 213 server 
response for any of the commands MFMT, MFCT and MFF because the server may 
not have exactly done what the client asked for.  The no-x-bit is just 
another example of such a situation.

> >
> >     219 approximate operation: the operation might not have been
> >         carried out to the client's full satisfaction, the client
> >         should examine the values listed in the response.
>
>Not sure I agree with that 219. I think that a 213 is returned, the
>client-PI MUST parse the response and can then at its discretion issues
>warnings/messages to the user if the requested and actioned times are very
>different.

The return code 213 is already in use for MDTM and SIZE.  And in these 
contexts the return data is always exact (the modification time of a file 
has an exact value) and the return data is exactly what the client asked 
for (the modification time).  With the MFXX commands is still exact but 
it's value may not be exactly what the client asked for.  Because of this 
difference a new return code could be used to make it clear for 
everyone.  But this is perhaps simply a question of my personal taste.


Regards

Wolfgang Zekoll

P.S.: David, you mentioned that someone could write something about UNIX 
permissions and FTP.  If you (or someone else) could point me to the "Draft 
Editors Guide and How-To for Beginners" I would consider doing the job.