Re: SFTP ACLs need inheritance support

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

denis bider wrote:
>>> 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?

What could a client do that is useful with the information that
a SACL exists but not knowing it's contents?

Unless you can think of something, I'm inclined to go the
simply route.

What would you think of SFX_ACL_ACCESS_CONTROL_INCLUDED and
SFX_ACL_AUDIT_ALARM_INCLUDED?

Thanks,

Joseph