Re: SFTP ACLs need inheritance support

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

denis bider wrote:
>> Do you think this should be added to SFTP v6, or do we need
>> a v7?
> 
> I think the changes I recommended are central to any SFTP
> client or server that implements ACLs, so I'd prefer them to
> be treated as such. For this reason, I would prefer a new ACL
> flags field into the Attributes structure. However, I could
> also live with the ACL flags field being an extension.

Remember, currently, the draft has no concept of DACL
and SACL, and the other OS that does ACLs that I'm
somewhat familiar with (VMS) does not seperate these,
and so forcing them to emulate the behavior of being
able to set these separately increases the complexity
of their servers.

Also, the meaning of a empty ACL is not universal; an
empty ACL in VMS is the same as no ACL, and both
mean defer to the permissions field.

In NT, it an empty ACL means grant no access; an
absent ACL means grant all access.

I don't know if VMS supports the concept of inheritable
ACLs (Richard, are you watching this thread?)  And if
it does, if it has a concept of "PROTECTED" like NT
does.

It may be that we need some increased complexity anyway
to make it so that the client can predict what behavior
will be if it sets an ACL with no ALLOW/DENY entries.

Regardless I'm trying to balance increasing complexity for
non-NT platforms with allowing NT platforms to communicate
all the information needed.

Using an extension, I think, accomplishes this nicely.
Under NT, fetching the permissions is expensive enough
that it isn't done all the time; hence the additional
overhead of an extension isn't too much.  I also tried
to define the extension in a way such that it wouldn't
need to be sent more often than not-- but given the
first point, I'm not sure this is worth it.

Servers that don't separate the two won't advertise
the extension, and clients will know not to send them.

Thanks,

Joseph