Re: A future for the SSH File Transfer Protocol?

[Simon Tatham <anakin%pobox.com@localhost>]

I wrote:
>>   http://www.tartarus.org/~simon/ssh/draft-sftp-userdb-00.txt

"Joseph Galbraith" <galb-list%vandyke.com@localhost> wrote:
> Whoops -- I didn't realize our conversation on this
> had wandered off the list.

Sorry, my fault. It's much more embarrassing to Reply To All when
you didn't want to than vice versa, so my MUA errs on the side of
caution :-)

> As I mentioned in my previous mail, NT doesn't use simple 4 byte
> user identifiers.  Given that the UID field MUST be present, I
> couldn't implement this under NT.

Arrgh, yes, you're right of course. And you're also right in
pointing out that if we introduce any kind of user identifier that
is neither a uid or a name, people will want to do lookups keyed on
that and the requests won't generalise. But I don't think _changing_
from numeric UIDs to strings is the way forward - the numeric UIDs
are well established in SFTP already and it would be better to give
the option of sticking with them.

How about this as a redraft?

 - We modify the USER data type so that the uid field is optional
   just like the rest of them. Similarly with the GROUP and gid.

 - Returned USER data structures can encode the NT opaque user
   identifier blob as an extended data item; either you or I will
   have to define a name for it.

 - Instead of separate getuserbyname and getuserbyuid calls, we have
   a single "getuser" call, whose argument is itself a USER data
   type. So to look up a user by name, you provide a USER instance
   which only contains the username field; to look up one by numeric
   uid you provide only the uid field; and to look up one by their
   NT opaque user identifier blob, you provide a USER instance
   containing none of the standard fields and _only_ containing the
   NT-opaque-user-id extended data item. The getuser call then
   returns a USER instance with all the other fields filled in.

That at once simplifies the protocol and makes it more extensible,
in case someone else comes up with yet another weird user ID type.
Are you happy with it? Should I do a proper redraft on that basis?

(Incidentally I've only just noticed I didn't actually provide
values for the SSH_FILEXFER_UDB_GID defines. Must supply those in
the redraft :-)

>      uint32   id
>      string   sftp-userdb-getuserbyuid%sgt.greenend.org.uk@localhost
>      uint32   count
>      count occurrences of 
>          uint32   uid

... so you can look up more than one at a time? Fair enough,
although I'm not sure I see a massive benefit. Of course, under the
above scheme that would become

     uint32   id
     string   "sftp-userdb-getuser%sgt.greenend.org.uk@localhost"
     uint32   count
     count occurrences of 
         USER     user

> uid or usernames that don't occur in the resultant list are assumed
> to have been unresolvable.

Do you not think it would be better to return some sort of error
code? I know some people already don't like SFTP because of its
paucity of distinguishable error returns; I'm trying to persuade
some Cambridge University people to propose a protocol extension
that provides more detailed errors. Best not to repeat the same
mistakes...

Cheers,
Simon
-- 
Simon Tatham         "Every person has a thinking part that wonders what
<anakin%pobox.com@localhost>    the part that isn't thinking isn't thinking about."