Subject: Re: A future for the SSH File Transfer Protocol?

From: "Joseph Galbraith" <[email-masked]>
Date: Fri, 9 Nov 2001 13:59:56 -0700

> "Joseph Galbraith" <[email-masked]> wrote:
> 
> > I'm definitely interested in this.  Can you repost your proposal?
> 
> Certainly. It's available as a text file from
> 
>   http://www.tartarus.org/~simon/ssh/draft-sftp-userdb-00.txt

Whoops -- I didn't realize our conversation on this
had wandered off the list.

I've actually had a chance to read the proposed
extension now -- and realized I actually did read
it when you originally posted it :-)

Here are some comments (some of which you've seen
in the mail that wandered off the list.)

> The USER data type, encoding a user database entry,
> is defined here:
>
>   uint32   flags
>   uint32   uid            always present
>
> The `uid' field specifies the numeric user ID of the entry. It MUST
> have the same meaning as the numeric user IDs used in the ATTRS
> compound data type in the main SFTP protocol. The `uid' field has no
> corresponding flag and MUST be present.

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.

So I think we should use the opaque

  string identifier

here as well.  (See my previous email to the list
"uid & gid in sftp")

The same thing applies in the GROUP data type for
gid.

Also, I would suggest that the requests actually be
as follows:

     uint32   id
     string   [email-masked]
     uint32   count
     count occurrences of 
         uint32   uid

and the reply format be:

     uint32   id
     uint32   count
     count occurrences of
         USER     user

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

What do you think?

- Joseph

---

From: Simon Tatham <[email-masked]>
Date: Fri, 09 Nov 2001 23:30:16 +0000

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

>      string   [email-masked]

... 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   "[email-masked]"
     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
<[email-masked]>    the part that isn't thinking isn't thinking about."