Re: Minor comments on draft-ietf-secsh-filexfer-04

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

> Section 5.5 "Permissions": "...as defined by POSIX [1]": [1] isn't
> POSIX. It would also be nice to have the relevant bit quoted so the
> draft stands without POSIX.

In fact, posix does not define the bit values, only
that macros of a given name exist, and so is worthless
in specifying a protocol where implementation must
agree about the meaning of the bits.

We had run into this when we realized AIX was giving
us back a bit value we didn't recognize and asked
the question, what would happen if this was sent over
the wire? And started poking.

The next version of the draft defines the values.

> Section 5.6 "Times": "A negative value..." [for atime etc]: atime and
> friends are defined as `uint64' in sec 5.
>
> > > From draft-ietf-secsh-architecture-14, `uint64' "represents a 64-bit
> unsigned integer", so can't go negative.
>
> The architecture draft doesn't define signed types, so some words
> indicating that that the putative "uint64" is to be treated as 2's
> complement signed yadda yadda are probably needed.

I may introduce a int64 type for sftp instead.
This seems better than saying unsigned, but not
really.

> Section 6.11 "Canonicalizing the Server-Side Path Name" (SSH_FXP_REALPATH):
> It's not too clear how much of the path needs to exist at the time
> REALPATH is invoked. This may cause interoperability problems.
>
> At least one implementation (psftp) contains workarounds to handle
> variant server responses to REALPATH("../path/to/nonexistent") where
> "../path/to" exists but the path component "nonexistent" doesn't (for
> instance when the client is planning to create a file or directory).
>
> Some servers will apparently complain because "nonexistent" doesn't
> exist, whereas others don't mind.
>
> Not sure what the right fix is - it's probably more important that it's
> defined than how it's defined. A conservative one would be to require
> the path to exist in its entirety (so in the above case, clients would
> ask about the destination directory, and then splice the filename on the
> end). This would remove ambiguity about how it's intended to be used;
> however, there are a few cases where 
>    realname(path) + "/" + leaf  !=  realname(path + "/" + leaf)
> for instance, if the client plans to mkdir(".."). This probably doesn't
> matter.

This one is a little bit trickier--
realpath is often implemented using the
unix library function of the same name,
which, I believe, fails if the path
doesn't exist.

Currently, our server doesn't fail if the
path doesn't exist (being windows, it doesn't
use realpath of course.)

However, if realpath failed for nonexistent
files or directories, a separate stat call would
not be required for chdir operations on the client.

I believe this is the route I will take.

Thanks,

- Joseph