On Thu, Oct 21, 2010 at 05:29:49PM -0400, Scott Cantor wrote:
> > Well, you can tell people "don't do that". Mainly I was wondering if
> > Moonshot had come to consensus on this. From your and Nico's replies
> > I'm taking you plan to support it under a "it's your foot, shoot it if
> > you want" philosophy.
>
> That would be mine, but I think Nico was saying there's some other notion
> that sounds like a local workaround to the problem?
The right approach, IMO, is to indicate that not all attributes [that
might be relevant to DENY ACL entries] are available. The acceptor
application can then reject access if it knows it has (or might have)
ACLs with such entries.
If there are no such ACEs then the acceptor app can continue, which can
be useful to do in the face of transient failures. The acceptor app
should choose what to do.
It is important to identify what types attributes can be used to match
DENY ACEs.
> [...]
> As for whether it's possible or not, I'm not sure offhand, but I believe not
> right now. I think I'm trapping those errors too far from this code to
> surface them. I don't know how fixable that is, I'll have to look into it.
This has been a problem in layered APIs. A great example is Mozilla
libldap + Cyrus SASL + MIT or Heimdal gss/krb5 -- all GSS errors tend to
get aliased into one libldap error. This is a case with _five_ layers
(SASL is two layers, and GSS is two more).
> I guess my general response is that my experience with surfacing detailed
> information to apps hasn't been terribly successful at changing their
> behavior.
The first problem is dealing with the error handling limitations of each
layer, which often requires extensive surgery (and API extensions) or
outright new APIs (too much work). The second is that often apps can
only pass detailed error information to users, as opposed to acting on
detailed error information to remediate the situation (often there's
nothing they could do to remediate the situation). But one must not
underestimate the value of making detailed error information available
to the user.
Nico
--
|