Re: SFTP ACLs need inheritance support

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

>> 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
>
> Okay, I see why we need this in the protocol.
> However, I don't think there is any difference between
> an empty SACL and an absent SACL like there is between
> a empty DACL and an absent DACL.

That is correct, in the filesystem itself, there isn't a difference between an empty SACL and an absent SACL.

I'm wondering if perhaps I should have suggested different names for the PRESENT flags.

Windows uses the SE_DACL_PRESENT and SE_SACL_PRESENT flags to describe the actual contents of the security descriptor, e.g. as stored for a file on disk. This maps directly to how the suggested SFX_DACL_PRESENT and SFX_SACL_PRESENT flags would be used when sent in a STAT response from a Windows SFTP server.

However, when a Windows application modifies an existing security descriptor for a file, it doesn't use the SE_DACL_PRESENT and SE_SACL_PRESENT control flags in the security descriptor. Instead, there is an out-of-band parameter to SetFileSecurity() and other functions. The parameter is named SecurityInformation, and it dictates what portions of the security descriptor will be modified. The defined bits for this parameter include DACL_SECURITY_INFORMATION and SACL_SECURITY_INFORMATION.

My proposal was that when the client sends a SETSTAT request to a Windows SFTP server, the SFX_DACL_PRESENT and SFX_SACL_PRESENT flags take on the meaning of the SecurityInformation parameter. In this case, therefore, there is not a direct mapping to SE_DACL_PRESENT and SE_SACL_PRESENT flags. In fact, it may be misleading that the name of the SFTP flag suggests that.

For this reason, therefore, it may be prudent to choose a third name for the SFTP flags. Perhaps the names should be SFX_DACL_INCLUDED and SFX_SACL_INCLUDED.

We might even consider separating the "included" meaning from the "present" meaning by defining separate flags. For example, responding to a STAT request, the server may be able to tell the client that there is a SACL defined, but may not be able to send the actual contents. Thus the SFX_SACL_PRESENT flag would be on, but the SFX_SACL_INCLUDED flag would be false.

What do you think? Shall we separate the two purposes or shall we just mesh them together, as was so far discussed?