IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



Richard Whalen wrote:
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.

I'd forgotten about the traditional access mask.

Would it be useful to allocate some additional bits in
the permissions mask to represent the extra data in
this field?

Also, does an empty (as opposed to absent) ACL deny
all access?

Thanks,

Joseph

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








Home | Main Index | Thread Index | Old Index