WebDAV conference calls
May 12, 2000: 11am –
June 2, 2000: 11am – 12:00 pm
Anne Hopkins – Microsoft
Eric Sedlar – Oracle (taking notes)
Geoff Clemm – Rational
methods on an object must be controlled by some right. Denying all rights should prevent any
HTTP access to that resource. Authors of Internet drafts will have to define a new right,
or map to existing rights for each new method defined.
default, all rights are denied
resources must have an ACL defined on them (the ACL property may not be
NULL). Implementations that
support null ACLs must generate a "standard" ACL that specifies
what rights are available in that case
lists apply individually and combinatorially. A right granted when requested by itself is also granted
when requested in combination with any other rights.
A change to what came before:
- The combination
of source resource (from inheritance) and principal are now the unique key
for an ACE, not just the principal.
How can the client identify which ACE for a particular
principal is used. (Should there be some
kind of ACTIVE boolean attribute on the ACE to differentiate which of the
ACEs from the various source resources is used?
Incremental ACE changes vs. replacing all previously
Do we need a mechanism to discover the method the server
uses to define ACE interactions, and list the possible methods?
proposed making ACL changes incremental, rather than replacing all of the
previously visible ACEs as proposed earlier, with rules specifying that
setting an ACE with no rights has the effect of deleting that ACE. An ACE with no rights is never maintained in an ACL. ACL method processing is as follows:
an ACE with no rights is specified in the ACL method, any previously
existing ACE for that source resource/principal is deleted
there are rights specified, and an ACE with that source resource/principal
already exists, those rights are replaced on the existing ACE.
there was not previously an ACE with that source resource/principal, that
ACE is added
On the June 2 call, Eric pointed
out that the problem with this change is that it doesn't address ordering
issues that may be required in some implementations. Disposition of this proposal is still unresolved.
proposed a discovery mechanism describing how a particular server resolves
ACE conflicts, postulating that there are really not very many ways of
handling this. There is the
"specific ACEs trump more general ones" or the "user ACEs
trump group ACEs" rule, and there is another rule involving unioning
all applicable ACEs with denies trumping grants. However, given the later discussions on how NT ACE
evaluation works, it's not clear that this will have any practical
was a lot of discussion in the June 2 call on how the NT ACE evaluation
mechanism works. NT keeps the ACEs
ordered, and will stop with the first ACE denying any of the requested
rights, or when all rights requested are granted. It turns out that this mechanism has an
anomaly where granted rights don't always apply combinatorially, since if
the ACEs (in order) were: 1) Grant
user read, 2) Deny user read, 3)
Grant user write; if the user requested just the read right, access would
be granted, but if the user requested read & write, processing
wouldn't stop until ACE 3, and read access would be denied. Anne said that NT relies on clients to
avoid this confusing condition by forcing deny ACEs to come before grant
Another issue on NT is the issue of NULL ACLs, which mean that there is NO
access control on that particular file, whereas an ACL with no ACEs grants
no rights to anyone. Geoff pointed
out that confusing null ACLs with empty ACLs is very likely to cause
programming errors and incompatibilities, so we specified that ACLs cannot
be NULL, and implementations can use a generated or special case ACL to
handle null ACLs.
discussion around the issue of whether or not to use methods or properties
to set ACLs. One difficulty with
going to the property implementation is that we had postulated that
separating out ACLs from the rest of the properties would provide an
opportunity to avoid the expense of calculating the source-resource
attribute for an ACE on NT, whereas this would be more difficult to
separate out with properties.
Currently there is no way to use XPath or any such syntax to
identify subparts of nested XML tags to be retrieved or not.