Re: SFTP ACLs need inheritance support

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

> 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.


> Has anyone begun implementing yet?

I will soon be done implementing the current v6 draft. Of course my implementation already anticipates the suggested changes.


> I did try to address the dacl presence / absence
> problem, but in the end, it seemed _very_ windows
> specific.

It doesn't seem to me that the presence/absence flag hurts people on other platforms. Does it?

 From my experience at least, not having them makes it a factor of magnitude more difficult to implement this right in Windows.


> What would you think of the following extension:
>
> string "win32-acl-flags"
> string extension-data
>   uint32 acl-flags

I'd remove the win32 reference. Any client or server can send this extension if it wants to.


> SFX_SACL_PRESENT
> This bit need be set if and only if the SACL
> is present and empty (0 AUDIT/0 ALARM entries in
> the ACL.)
> NOTE> Does this even have significant meaning?

Oh, it does.

Without this flag, it is very difficult for the server to know whether the client, having sent a list of ACLs that does not include any AUDIT or ALARM entries, wants the server to (a) clear the SACL, or (b) not touch the SACL at all.
The Windows DACL and SACL are edited separetely. Any access to the SACL requires the SeSecurityPrivilege to be enabled, and a special access flag to be included when the file is opened. Also, in a large majority of cases, the user wants to modify just the DACL, not also the SACL.

Suppose the client sends an ACL with no AUDIT or ALARM entries. If the server goes ahead and tries to clear the SACL, but fails, it cannot know whether to respond with an error (because perhaps the user wanted to clear the SACL) or success (because perhaps the user didn't want to clear the SACL, and doesn't have privilege to do it in the first place).

Please do include also the ACE mask flag for ACCESS_SYSTEM_SECURITY. Sure, it's Windows specific, but it improves compatibility and is very easy to add. The spec should say that anyone who wants to read or write AUDIT or ALARM ACEs from an opened file handle should have passed this flag when opening the handle. Servers that have no need for this flag can simply ignore it, as can clients that don't intend to query a Windows server for ACLs.


Best regards,

denis