Subject: additional ACE flag required in SFTP draft?, speling and grammer fikses

From: denis bider <[email-masked]>
Date: Sun, 26 Feb 2006 17:15:00 +0100

Hello Joseph, everyone -

I got around to continuing our SFTP v6 implementation, and I am now trying to synchronize my existing implementation (according to draft 10) with the latest version of the draft (12).

Among other things, draft 12 defines:

  ace-flag

    A combination of the following flag values.  See NFS Version 4
    Protocol [RFC3010] section 5.9.2:

    ACE4_FILE_INHERIT_ACE           0x00000001
    ACE4_DIRECTORY_INHERIT_ACE      0x00000002
    ACE4_NO_PROPAGATE_INHERIT_ACE   0x00000004
    ACE4_INHERIT_ONLY_ACE           0x00000008
    ACE4_SUCCESSFUL_ACCESS_ACE_FLAG 0x00000010
    ACE4_FAILED_ACCESS_ACE_FLAG     0x00000020
    ACE4_IDENTIFIER_GROUP           0x00000040

Unfortunately, when sending an ACL, the lack of an INHERITED value among these flags provides the server with no way to inform the client which of the included ACEs are inherited and which are defined explicitly for the object for which the ACL is being sent.

I propose that an additional ACE flag is required which will allow the server to convey to the client the information that a certain ACE is inherited (or isn't).

I would also like to report the following spelling/grammar errors - which probably is not an exhaustive list, but regardless. :)

 - "The ACE data structure is composes as follows:"
                              ^^^^^^^^

 - "If the both the INCLUDE and the PRESENT bit are set"
       ^^^

 - "but their are no ALLOW/DENY entries in the list"
        ^^^^^

 - "into a ACL"
         ^^^^^

 - "the clients intent"
        ^^^^^^^

 - "capabilities that the user may have in to allow"
                                        ^^?^^

 - "restore the file from backup medium"
                     ^^^^?^^^^^^^^^^^^^

 - "their may be other uses for this data"
    ^^^^^

Best regards,

denis

---

From: denis bider <[email-masked]>
Date: Sun, 26 Feb 2006 18:44:42 +0100

I also spotted this detail. The SFTP 6 draft (version 12) defines:

  ace-mask

    Combination of the following flags (taken from [RFC3010], section
    5.9.3.  The semantic meaning of these flags is also given in
    [RFC3010].

       ACE4_READ_DATA         0x00000001
       ACE4_LIST_DIRECTORY    0x00000001
       ACE4_WRITE_DATA        0x00000002
       ACE4_ADD_FILE          0x00000002
       ACE4_APPEND_DATA       0x00000004
       ACE4_ADD_SUBDIRECTORY  0x00000004
       ACE4_READ_NAMED_ATTRS  0x00000008
       ACE4_WRITE_NAMED_ATTRS 0x00000010
       ACE4_EXECUTE           0x00000020
       ACE4_DELETE_CHILD      0x00000040
       ACE4_READ_ATTRIBUTES   0x00000080
       ACE4_WRITE_ATTRIBUTES  0x00000100
       ACE4_DELETE            0x00010000
       ACE4_READ_ACL          0x00020000
       ACE4_WRITE_ACL         0x00040000
       ACE4_WRITE_OWNER       0x00080000
       ACE4_SYNCHRONIZE       0x00100000

This matches quite directly the file access rights available in Windows. However, it omits one special access right that has to do with accessing AUDIT and ALARM ACL entries - the ACCESS_SYSTEM_SECURITY access right. According to MSDN ("SACL Access Right"):

  The ACCESS_SYSTEM_SECURITY access right is not valid
  in a DACL because DACLs do not control access to a SACL.
  However, you can use the ACCESS_SYSTEM_SECURITY access
  right in a SACL to audit attempts to use the access right.

This flag is not used in ALLOW and DENY ACEs. However, it can appear in an AUDIT or ALARM ACE, in which case it can be useful for auditing unauthorized attempts to access the AUDIT/ALARM part of a file's access control list.

I suggest that it would be straightforward and useful to define a value for this access right in SFTP.

denis