Subject: SFTP owner, group and mode flags...

From: "Joseph Galbraith" <[email-masked]>
Date: Wed, 20 Mar 2002 15:22:27 -0700

The current specification of SFTP passes owner and
group information as UID and GID, and specifies
file permissions as a UINT bit mask.

This has several problems:

1. A UINT32 is not sufficient to represent
   UID and GID on Windows NT systems.

2. There is no mechanism for translating between
   the UID/GID and a human readable form (the
   owner name or group name.)

3. The permission mask is unable to represent
   the more sophisticated security information
   used under VMS, Windows NT and some Unix
   variants -- ACLs.

I would propose the following:

* Where we currently pass UID and GID as
  integers, pass them as strings of the
  form user@dns (see NFS: RFC3010, Section 5.6.)

* In order to reduce overhead of readdir and
  stat operations, which will increase with
  the above, we add a parameter to the opendir
  and stat protocols to allow the client to
  specify what attributes it is interested in.

  This also allows the client to optimize stat
  and readdir operations.  The client can avoid
  asking for information it isn't interested in,
  and minimize the work requested of the server
  and the amount of data transfered over the wire.

* Also, now that the user / group information
  is available in a human readable format, the
  long name is entirely redundant, and expensive
  (more than twice as long as the rest of the stat
  data put together.)

  I propose that we remove it, and the associated
  temptation for applications to parse it as
  Unix ls output.

* Change the mode field to a type field, which indicates
  the type of the file, and make it a byte field.

* Use the ACL specification from NFS (RFC3010, Section 5.9)
  Unix style permission masks can be easily represented as
  an ACL using the special "who" values specified in
  5.9.4.

* We allow a server to advertise what attributes
  it can provide and what attributes it can provide
  efficiently, but require servers to tolerantly
  ignore requests for attributes it can't provide
  and require that clients be prepared to not receive
  attributes that the server has advertised.

  For example, under NT, we would advertise that we
  can provide User, Group and ACL information, but
  that they are expensive.

  However, if the file-system supporting a file requested
  by the client is FAT, then we won't be able to provide
  that information.

- Joseph

---

From: Damien Miller <[email-masked]>
Date: Thu, 21 Mar 2002 11:36:10 +1100 (EST)

>   form user@dns (see NFS: RFC3010, Section 5.6.)

Agreed.

>   specify what attributes it is interested in.

I don't know whether this is necessary. If the longname is eliminated, 
then I don't think the replies will be very large.

>   temptation for applications to parse it as

Agreed.

>   the type of the file, and make it a byte field.

Can you be more specific? 

>   an ACL using the special "who" values specified in

Again, this add complexity for the simple case. Why not encode extended 
ACLs as a seperate attribute?

>   can provide User, Group and ACL information, but

What do you mean by expensive? I am a little ambivalent against 
advertising capabilities, especially ones relating to whether certain
operations are "expensive" for the host OS. 

-d

---

From: "Joseph Galbraith" <[email-masked]>
Date: Thu, 21 Mar 2002 09:20:23 -0700

> then I don't think the replies will be very large.

Sorry, I should have tied this better with

> operations are "expensive" for the host OS. 

Here's what I'm thinking.  It is expensive for me to
get user, group and security information.  I.e., returning
user, group and security information slows a directory listing
down by more than an order of magnitude.

So, right now, since I have no clue whether the client really
wants the information, I never return it.

If, on the other hand, I could both tell the client
that it was relatively expensive to ask for that
information, and know that the client really wanted
to use the data, I could return the information.

The client could make an informed decesion about
whether it wanted the security information or
not, knowing that it is expensive for my server
to acquire that information.

And my server would know that the client really
intended to do something with the information
if it asked for it.

Even if we didn't allow the server to advertise,
it would still be useful to know what the client
wanted.

> Can you be more specific? 

Sorry, I've had a couple of questions on this;
I definitely wasn't clear (and may have used
the wrong term, too.)

There are two peices of information encoded into
the permissions field of that sftp attribute
structure.

* The file type
* The access control information (permissions)

I was proposing that we seperate out the file
type into a BYTE field, and do away with the
permissions field in favor of ACLs.

However, I don't feel strongly about doing away
with the permissions field.  In fact, after thinking
about it, I realized that it might not be so easy to
encode things like the sticky bit in an ACL, so there
may be good reason not to.

But, I do feel strongly about splitting the two
pieces of information into seperate fields.

In particular, my NT server can't send valid information
for the permissions field, but can send valid type
information.  So right now, it lies about the permissions.

- Joseph