Subject: SFTP ACLs need inheritance support

From: denis bider <[email-masked]>
Date: Sun, 4 Dec 2005 00:57:18 +0100

Hello all,

I believe the ACL support which SFTP has lifted from NFS v4 is insufficient. It seems as if this system was developed directly with Windows NT4 ACLs in mind. It does not support inheritance which is an important feature of NTFS file security since Windows 2000.

To address this, I suggest the following additions to the SFTP draft:

1. In the Attributes structure, in addition to the ACL string, there should be an "ACL flags" value containing any combination of the following values:

  DACL present = ...
  DACL protected = ...
  SACL present = ...
  SACL protected = ...

Without the DACL present and SACL present flags, there is no way for a server to know whether the client, by sending an ACL with no system audit entries, wishes to clear the SACL or leave it intact. This is important because a special privilege is required to set or clear the SACL, and this privilege is not held by regular users. An explicit flag would make it easier for the server to determine the user's intent.

The "protected" flags are necessary to control inheritance of ACEs from the parent container. Without these flags, there is no way for the SFTP client to control ACE inheritance.

2. The ACE flags need to be extended with something like "INHERITED_ACE_FLAG". When the client retrieves an ACL, this flag would be set by the server to indicate that the particular ACE entry is inherited from a parent directory. The SFTP client would 

Obviously we probably won't call this ACE4_INHERITED_ACE_FLAG, since this flag is not in NFS v4.

3. Optionally, one might also choose to support "inherited from" information so that the SFTP client could be told about the source of an inherited ACE.

I believe these changes are necessary to implement a quality SFTP client. If these additions are not agreed to, I will have to devise a private extension for them. That will be bad for interoperability.

If these additions are incorporated into the SFTP draft, they could be made backwards compatible by specifying the Attributes structure ACL flag as an extension. However, as far as I'm concerned, the protocol version might also be bumped up to 7; that seems a bit cleaner, but otherwise it is all the same to me.

So, what does everyone think?

Best regards,

denis

---

From: denis bider <[email-masked]>
Date: Mon, 5 Dec 2005 15:14:00 +0100

Hello all,

I think we are also missing an ACE mask flag for accessing system security.

When communicating with a Windows server, a client can open a file with READ_ACL and WRITE_ACL masks which will allow it to read or write the DACL later. However, the client has no way of opening a file handle in a way that will allow it to read or write AUDIT ACEs. In order to do this, the client needs to request the ACCESS_SYSTEM_SECURITY access right when opening the file, and the server needs to enable the Security privilege for the duration of the file open attempt.

We need an ACE mask flag that will be equivalent to ACCESS_SYSTEM_SECURITY. I suggest allocating 0x00200000 for this.

Best regards,

denis

On Sun, 4 Dec 2005 00:57:18 +0100, denis bider wrote:
> Hello all,
>
> I believe the ACL support which SFTP has lifted from NFS v4 is
> insufficient. It seems as if this system was developed directly
> with Windows NT4 ACLs in mind. It does not support inheritance
> which is an important feature of NTFS file security since Windows
> 2000.
>
> 1. In the Attributes structure, in addition to the ACL string,
> there should be an "ACL flags" value containing any combination of
> the following values:
>
> DACL present = ...
> DACL protected = ...
> SACL present = ...
> SACL protected = ...
>
> Without the DACL present and SACL present flags, there is no way
> for a server to know whether the client, by sending an ACL with no
> system audit entries, wishes to clear the SACL or leave it intact.
> This is important because a special privilege is required to set or
> clear the SACL, and this privilege is not held by regular users. An
> explicit flag would make it easier for the server to determine the
> user's intent.
>
> The "protected" flags are necessary to control inheritance of ACEs
> from the parent container. Without these flags, there is no way for
> the SFTP client to control ACE inheritance.
>
>
> 2. The ACE flags need to be extended with something like
> "INHERITED_ACE_FLAG". When the client retrieves an ACL, this flag
> would be set by the server to indicate that the particular ACE
> entry is inherited from a parent directory. The SFTP client would
>
> 3. Optionally, one might also choose to support "inherited from"
> information so that the SFTP client could be told about the source
> of an inherited ACE.
>
>
> I believe these changes are necessary to implement a quality SFTP
> client. If these additions are not agreed to, I will have to devise
> a private extension for them. That will be bad for interoperability.
>
> If these additions are incorporated into the SFTP draft, they could
> be made backwards compatible by specifying the Attributes structure
> ACL flag as an extension. However, as far as I'm concerned, the
> protocol version might also be bumped up to 7; that seems a bit
> cleaner, but otherwise it is all the same to me.
>

---

From: Joseph Galbraith <[email-masked]>
Date: Mon, 05 Dec 2005 21:49:10 -0700

Do you think this should be added to SFTP v6, or
do we need a v7?  Has anyone begun implementing
yet?

What do others think?

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

I've started twice today to spec something out, and
haven't liked what I got either time... I'm tempted
to do this with an extension.

What would you think of the following extension:

string "win32-acl-flags"
string extension-data
  uint32 acl-flags

If the extension is not absent, then all
bit values default to '0'

SFX_DACL_PRESENT
  This bit need be set if and only if the DACL
  is present and empty (0 ALLOW/0 DENY entries
  in the ACL.)  If the DACL is present and empty,
  this implies that no access is granted.

  If the DACL is not present (i.e., 0 ALLOW/0 DENY
  entries) this implies that access to the file
  is either granted to all users or governed by
  another mechanism, such as the permissions
  mask.

SFX_DACL_PROTECTED
  If this bit is set, then the DACL may not be
  modified by inherited ACEs.

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?

SFX_SACL_PROTECTED
  If this bit is set, then the SACL may not be
  modified by inherited ACEs.

Thanks,

Joseph

---

From: denis bider <[email-masked]>
Date: Tue, 6 Dec 2005 14:58:36 +0100

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

> problem, but in the end, it seemed _very_ windows

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:

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

> 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

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 06 Dec 2005 08:02:23 -0700

> 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

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.

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

Yes, I see that.

Thanks,

Joseph

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 06 Dec 2005 08:32:09 -0700

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

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 06 Dec 2005 09:01:17 -0700

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

I'll do that.

Here is what I'm planing:

ACCESS_PRIV_SYSTEM_SECURITY = 0x00000200
  The server should access the file in such a way the
  reading and writing an ACL with AUDIT/ALARM entries
  is permitted.

  Systems that don't require special privileges to
  write system audit or alarm events SHOULD ignore
  this bit during the open request.  Servers that
  do not support AUDIT or ALARM ACE types should fail
  the open operation with NOT_SUPPORTED.

ACCESS_PRIV_BACKUP_FILE     = 0x00000400
  The server should access the file in order to back it up.

  Servers that don't need to perform any special processing
  in order to gain access to a file for backup purposes
  should ignore this bit during an open request.

ACCESS_PRIV_RESTORE_FILE    = 0x00000800
  The server should access the file in order to restore it.

  Servers that don't need to perform any special processing
  in order to gain access to a file for purposes of restoring
  from backup should ignore this bit during an open request.

ACCESS_PRIV_OVERRIDE_OWNER  = 0x00001000
  This bit indicates that the client wishes to override the
  WRITE_DAC permission on the file.  If the server does not
  support this operation, it must return NOT_SUPPORTED.

  If the user does not have ability to override the
  WRITE_DAC permission on the file, the operation should
  fail with ACCESS_DENIED.

I choose these bits because they are still "specific bits"
in the NT world of structured access masks.  I'll probably
also add text like this, someplace:

  When requesting all access to a file, a client SHOULD
  NOT as a matter of course include the ACCESS_PRIV_*
  bits.  These bits should only be requested when the
  operation described is specifically intended.

Does this fit your needs?

Thanks,

Joseph

---

From: denis bider <[email-masked]>
Date: Tue, 6 Dec 2005 17:21:03 +0100

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

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 06 Dec 2005 09:42:07 -0700

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

---

From: denis bider <[email-masked]>
Date: Tue, 6 Dec 2005 17:46:23 +0100

I think that's an excellent proposal!

The backup and restore flags could prove very useful to specialized software that performs backup over the network, as using these flags is really the only way to backup a file with multiple streams.

The "OVERRIDE_OWNER" flag appears to map directly to the WRITE_OWNER access right, without which it is not possible for an administrator to take ownership of an abandoned file.

I think it's great that an administrator will be able to use an SFTP client to do that!

---

From: denis bider <[email-masked]>
Date: Tue, 6 Dec 2005 17:58:20 +0100

> a SACL exists but not knowing it's contents?

Except that the client could hide the ability to edit the SACL for the particular file, I can't really think of something incredibly useful. It's just something I thought might be worth considering.

> SFX_ACL_AUDIT_ALARM_INCLUDED?

That would be fine with me. As a bonus, it's nice that these names aren't inherently platform-specific.

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 06 Dec 2005 10:05:30 -0700

denis bider wrote:
>> What could a client do that is useful with the information
>> that a SACL exists but not knowing it's contents?
> 
> Except that the client could hide the ability to edit the SACL
> for the particular file, I can't really think of something
> incredibly useful. It's just something I thought might be
> worth considering.

Hmmm... but the server is likely to have to attempt to enable
the privilege without even knowing if the client cares to
find this out.

It doesn't sound like you are strongly attached to this--
and if the client really wants to know, it can always attempt
to open the file as if it were going to modify the security
information itself before enabling the UI.

> That would be fine with me. As a bonus, it's nice that these
> names aren't inherently platform-specific.

That is precisely why I chose them.  Explaining these names in
the document is much easier (and less complicated) than
explaining DACL and SACL.

Thanks,

Joseph

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 06 Dec 2005 10:17:56 -0700

denis bider wrote:
> The backup and restore flags could prove very useful to
> specialized software that performs backup over the network, as
> using these flags is really the only way to backup a file with
> multiple streams.

Hmmm... I was thinking of these as simply enabling the
backup or restore privilege which bypasses access
checks-- which would be highly useful for things like
scanning the volume to see who is using what space--
also, if this turns on reading from the backup stream,
an non-NT backup stream aware application can't use
this feature.

So, I'd suggest that we also have an open flag:

  SSH_FXF_ACCESS_BACKUP_STREAM

  Requests that the server return data to the read request
  as a structured backup stream.  The format of the backup
  stream is system specific, but it should encode all the
  information that must be preserved in order to restore
  the file from a backup medium.  The only well defined
  use for this data is to write it to the same server to
  a file also opened with this flag specified.

  However, if the server OS has a well defined backup
  stream format, it may be that there are other uses
  for this data outside the scope of this protocol.

  When this flag is present, the server expects a backup
  stream in the write requests.

  Data offsets are in the READ and WRITE packets are ignored
  when this flag is specified.

What do you think?

Thanks,

Joseph

---

From: denis bider <[email-masked]>
Date: Tue, 6 Dec 2005 19:13:17 +0100

> scanning the volume to see who is using what space--

Based on my reading in the past few days (but not actual first-hand experience), it seems that Windows always requires not just a privilege but also a flag; i.e. the "SeSecurityPrivilege" goes hand in hand with ACCESS_SYSTEM_SECURITY flag (one is not useful without the other), and the "SeBackupPrivilege" goes hand in hand with the FILE_FLAG_BACKUP_SEMANTICS flag.

In other words, it is my understanding that you have to specify FILE_FLAG_BACKUP_SEMANTICS in order to get any kind of special behavior from Windows, and FILE_FLAG_BACKUP_SEMANTICS in turn means that you'll be reading from the backup stream, and you can't have one without the other.

My understanding may be incorrect.

---

From: denis bider <[email-masked]>
Date: Tue, 6 Dec 2005 17:31:35 +0100

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?

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 06 Dec 2005 11:46:52 -0700

denis bider wrote:
>> backup or restore privilege which bypasses access checks--
>> which would be highly useful for things like scanning the
>> volume to see who is using what space--
> 
> Based on my reading in the past few days (but not actual
> first-hand experience), it seems that Windows always requires
> not just a privilege but also a flag; i.e. the
> "SeSecurityPrivilege" goes hand in hand with
> ACCESS_SYSTEM_SECURITY flag (one is not useful without the
> other), and the "SeBackupPrivilege" goes hand in hand with the
> FILE_FLAG_BACKUP_SEMANTICS flag.
> 
> In other words, it is my understanding that you have to
> specify FILE_FLAG_BACKUP_SEMANTICS in order to get any kind of
> special behavior from Windows, and FILE_FLAG_BACKUP_SEMANTICS
> in turn means that you'll be reading from the backup stream,
> and you can't have one without the other.

FILE_FLAG_BACKUP_SEMANTIC in combination with
SeBackupPrivilege bypasses the read access checks
in the filesystem.

It doesn't require you to use BackupRead() or BackupWrite()
to my knowledge-- in other words, it is perfectly
reasonable to open a file file FILE_FLAG_BACKUP_SEMANTIC
and still call ReadFile/WriteFile.

So in fact, if an application wanted to make
tar file backups using the SFTP protocol,
it could do so by specifying ACCESS_PRIV_BACKUP_FILE
but not specifying SSH_FXF_ACCESS_BACKUP_STREAM.

However, if ACCESS_PRIV_BACKUP_FILE implied that
READ and WRITE data should return the backup
stream (which it would have to in order to
backup alternate data streams) it would no
longer be possible to do a tar file backup.

Thanks,

Joseph

PS. I'm tempted, as a win32 extension, to allow
a file to be opened as a directory in order to
enumerate the named streams.

---

From: denis bider <[email-masked]>
Date: Tue, 6 Dec 2005 20:39:13 +0100

> and still call ReadFile/WriteFile.

Ah, indeed, I got BackupRead() and the effects of FILE_FLAG_BACKUP_SEMANTICS mixed up.

Therefore ACCESS_PRIV_BACKUP_FILE means the server will open the file with FILE_FLAG_BACKUP_SEMANTICS, and SSH_FXF_ACCESS_BACKUP_STREAM means the server will I/O with BackupRead() / BackupWrite(). That sounds great, then!

Best regards

denis

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 06 Dec 2005 13:47:16 -0700

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

Hmm... well, lets try a proposal that doesn't use extensions,
and see how it comes out -- folks, let me know what you think!

ACE
      uint32   ace-type
      uint32   ace-flag
      uint32   ace-mask
      string   who [UTF-8]

ACL

uint32 acl-flags
uint32 ace-count
ACE    ace[ace-count]

acl-flags indicates information about the ACL
as a whole.

SFX_ACL_ACCESS_CONTROL_INCLUDED = 0x00000001
SFX_ACL_ACCESS_CONTROL_PRESENT  = 0x00000002
SFX_ACL_CONTROL_INHERITED       = 0x00000004
  If INCLUDE is set during a setstat operation, then the
  client intends to modify the ALLOWED/DENIED entries of
  the ACL.  Otherwise, the client intends for these entries
  to be preserved.

  If the PRESENT bit is not set, then the client wishes to
  remove control entries.  If the server doesn't
  support separate control and audit information, the client
  MUST not clear this bit without also clearing the
  AUDIT_ALARM_PRESENT bit.

  If the PRESENT bit is clear, then control of the file
  MAY be through the permissions mask.  The server MAY
  also grant full access to the file.

  If the both the INCLUDE and the PRESENT bit are set,
  but their are no ALLOW/DENY entries in the list, the
  client wishes to deny all access to the file or directory.
  The server may have to transform this into a ACL with
  a deny entry to implement it.

  If INHERITED is set, then ALLOW/DENY ACEs MAY be inherited
  from the parent directory.  If it is off, then they MUST
  not be INHERITED.  If the server does not support controlling
  inheritance, then the client MUST clear this bit; in this
  case the inheritance properties of the server are undefined.

SFX_ACL_AUDIT_ALARM_INCLUDED  = 0x00000010
SFX_ACL_AUDIT_ALARM_INHERITED = 0x00000020
  If INCLUDE is set during a setstat operation, then the
  client intends to modify the AUDIT/ALARM entries of
  the ACL.  Otherwise, the client intends for these entries
  to be preserved.

  If INHERITED is set, then AUDIT/ALARM ACEs MAY be inherited
  from the parent directory.  If it is off, then they MUST
  not be INHERITED.  If the server does not support controlling
  inheritance, then the client MUST clear this bit; in this
  case the inheritance properties of the server are undefined.

Because some server require special permissions / privileges
in order to modify the AUDIT/ALARM entries in the ACL, it
is important to communicate to the server the clients intent
to modify these entries.  The client MUST both use the
ACCESS_AUDIT_ALARM_ATTRIBUTES bit in the desired attribute
of the open request and must set the SFX_ACL_AUDIT_ALARM_INCLUDED
during the setstat operation.

Clients that do not intend specifically to modify the
AUDIT or ALARM entries SHOULD NOT request
ACCESS_PRIV_ACCESS_AUDIT_ALARM_ATTRIBUTES access and SHOULD NOT
set the SFX_ACL_AUDIT_ALARM_INCLUDED bit because these
operations are often privileged and will fail.

If the SFX_ACL_AUDIT_ALARM_INCLUDED is set, and the requested
change can not be made, the server MUST fail the request.

--

I believe rather than access flags, it makes more sense to
do these as open flags (since they can't be set in a ACL):

SSH_FXF_ACCESS_AUDIT_ALARM_INFORMATION = 0x00001000
  This bit indicates that the client wishes the server
  to enable any privileges or extra capabilities that
  the user may have in to allow the reading and writing
  of AUDIT or ALARM access control entries.

SSH_FXF_ACCESS_BACKUP               = 0x00002000
  This bit indicates that the client wishes the server to
  enable any privileges or extra capabilities that the user
  may have in order to bypass normal access checks for the
  purpose of backing up or restoring files.

SSH_FXF_ACCESS_BACKUP_STREAM        = 0x00004000
  This bit indicates that the client wishes to read or write
  a backup stream.  A backup stream is a system dependent
  structured data stream that encodes all the information
  that must be preserved in order to restore the file from
  backup medium.

  The only well defined use for backup stream data read in
  this fashion is to write it to the same server to a file
  also opened using the BACKUP_STREAM flag.  However,
  if the server has a well defined backup stream format, their
  may be other uses for this data outside the scope of this
  protocol.

ACCESS_OVERRIDE_OWNER                = 0x00008000
  This bit indicates that the client wishes the server
  to enable any privileges or extra capabilities that
  the user may have in order to gain access to the file
  with WRITE_OWNER permission.

  This bit MUST always be specified in combination with
  ACE4_WRITE_OWNER.

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

Unfortunately people (myself included) have already implemented
and shipped "supported2" -- the "supported2" and the "vendor-id"
seem to be pretty popular :-)

I'd suggest the following:

"acl-supported"
uint32 capabilities

  ACL_CAP_ALLOW = 0x00000001
  ACL_CAP_DENY  = 0x00000002
  ACL_CAP_AUDIT = 0x00000004
  ACL_CAP_ALARM = 0x00000008
    The client may use the associated ACE type.

  ACL_CAP_INHERIT_ACCESS      = 0x00000010
  ACL_CAP_INHERIT_AUDIT_ALARM = 0x00000020
    If these bits are clear, the SFX_ACL_INHERIT_*
    flags must be false.

  ACL_CAP_SEPERATES_AUDIT_AND_CONTROL = 0x00000040
    If this bit is clear, then either both SFX_ACL_INHERIT_
    bits must bet set or both must be clear.  This is also
    true for the SFX_ACL_*_INCLUDED bits.

What do you think?

Thanks,

Joseph

>>>> Do you think this should be added to SFTP v6, or do we
>>>> need a v7?
>>>> 
>>> 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.
>> 
>> 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
> 
> 
>

---

From: denis bider <[email-masked]>
Date: Wed, 7 Dec 2005 02:15:03 +0100

> What do you think?

That seems quite exhaustive!

All the right ingredients are there, I'm just not yet 100% about the text (the MUSTs and SHOULDs). I have to look at that from an implementor's perspective, and it's too late for that today.

If you don't hear otherwise from me tomorrow, I'm fine with the text.

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 06 Dec 2005 18:25:23 -0700

> That seems quite exhaustive!

Yes... I've discovered that if I'm not exhaustive, one
server does one thing and another does it a little different...
one of the things I've been aiming for in the later SFTP
drafts is a determistic behavior out of servers.  I.e.,
it either happens the way the client wants or it fails :-)

> All the right ingredients are there, I'm just not yet 100%
> about the text (the MUSTs and SHOULDs). I have to look at that
> from an implementor's perspective, and it's too late for that
> today.
> 

All right, if I don't here from you tomorrow, I'll try to
integrate this into the draft source.

Thanks,

Joseph