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

["Richard Whalen" <Whalenr%process.com@localhost>]

I don't think that it will interfere with VMS, or with inter operating with VMS.  All that it would change is the logic for processing ACEs would have to consider the value of both the boolean and the count.

Files on VMS may or may not have an ACL.  All files on VMS still have the traditional System, Owner, Group, and World discretionary access fields.  These each have bits for Read, Write, Execute (which is a subset of read, not the Unix Execute), and Delete. Each process has a default protection mask that is used when a file is created and the protection is not specified; there is no default ACL value for a process.

Richard

-----Original Message-----
From: Joseph Galbraith [mailto:galb-list%vandyke.com@localhost]
Sent: Tuesday, August 30, 2005 10:55 AM
To: Richard Whalen
Cc: ietf-ssh%NetBSD.org@localhost
Subject: Re: Changes to SFTP v6: change in acl present flag


Richard Whalen wrote:
> VMS only has a single access control list per file that
 > contains both discretionary access control entries
 > and audit / alarm entries.
> 
> The explanation that Windows NT has two ACLs per file
 > helps in explaining the motive for the change. I can
 > understand how the change could improve efficiency in
 > a pure Windows NT environment.  In a mixed environment
 > I think that it is a wash.

Will it interfere with VMS though?  Or with inter operating
with VMS?

For example, would it be unclear what the correct behavior
for your server is if a client attempted to set
'acl present' = false + an audit ace?

Does VMS have the ability to not have a acl on the file,
and does it mean that all access is granted to the file?

Thanks,

Joseph

> -----Original Message-----
> From: Joseph Galbraith [mailto:galb-list%vandyke.com@localhost]
> Sent: Tuesday, August 30, 2005 10:29 AM
> To: Richard Whalen
> Cc: ietf-ssh%NetBSD.org@localhost
> Subject: Re: Changes to SFTP v6: change in acl present flag
> 
> 
> 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
>>
> 
>