Re: Changes to SFTP v6: change in acl present flag

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

Richard Whalen wrote:
> I have not implemented SFTP v6 style attributes yet, but I
> don't understand why audit and alarm ACEs are being considered
> differently from access ACEs when setting the acl-present
> flag.

Well, at least under NT, they are maintained in a different
list-- normal ACLs are in the discretionary access control
list; audit / alarm ACEs are in the system access control
list...

Leading to the ability to have no Discretionary access control
list but still have audit / alarm entries.

So... I'm hoping to be able to implement this in a way
that can talk w/ other NT based servers correctly...

I didn't think VMS did this... it sounds like I was right?

Thanks,

Joseph

> -----Original Message-----
> From: ietf-ssh-owner%NetBSD.org@localhost [mailto:ietf-ssh-owner%NetBSD.org@localhost]On
> Behalf Of Joseph Galbraith
> Sent: Tuesday, August 30, 2005 10:01 AM
> To: ietf-ssh%NetBSD.org@localhost
> Subject: Changes to SFTP v6: change in acl present flag
>
>
> Do we have people already shipping SFTP v6
> style attributes?
>
> Implementation experience has just taught me that
> I need both the boolean acl-present and the count field
> in the ACL.
>
> Even when the access control part of the acl is not
> present, there still may be auditing / system alarm
> entries present.
>
> I propose changing the current text to the following:
>
> > If the 'acl-present' flag is not set, it indicates that
> > the file does not have an ACL, as opposed to having an
> > empty ACL.  An empty ACL grants no access, not having
> > an ACL grants all access. This is distinct from the
> > case of SSH_FILEXFER_ATTR_ACL not being present in the
> > attrib flags. If SSH_FILEXFER_ATTR_ACL is not present,
> > the client can not deduce whether the server does not
> > support ACLs, did not check the ACL (because doing
> > so was expensive), or had some other reason for
> > omitting the data.
> >
> > When the 'acl-prenent' flag is not set, there may still
> > be system audit or alarm type entries in the list.
>
> Thanks,
>
> Joseph