Re: SFTP ACLs need inheritance support

[denis bider <ietf-ssh%denisbider.com@localhost>]

I don't have any major complaints about including the ACL flags as an extension to Attributes.

NT4 is also a platform that supports ACLs but not inheritance. We support it.

I don't think the presence of inheritance flags hurts any platform that doesn't support them. Such a platform can simply ignore those flags.

It may however be useful if a server can advertise that it supports ACL inheritance via the "supported2" mechanism in the version packet.

What would be a good way to advertise that?


On Tue, 06 Dec 2005 08:32:09 -0700, Joseph Galbraith wrote:
> 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