Re: [Ace] Extended REST model comment

[Carsten Bormann <[e-mail]>]

On 2020-06-30, at 16:43, Jim Schaad <[e-mail]> wrote:
> 
> In trying to formalize a policy for the RD testing, I ended up with
> something that I think needs to be noted in this section.  There is a
> difference between the following statements:
> 
> Access is granted to resources created by the client.
> Access is granted to resources that could have been created by the client.
> 
> The first is what the text seems to cover.  This make sense in for the
> coffeepot where only the person who created the order should be able to
> cancel it.  (Well maybe an administrator might need to as well.)  However it
> does not cover the case where an installer created a number of entries in
> the RD.  A QA person then comes through to make sure the installation was
> done correctly.  When he finds a problem, the first statement requires that
> the original installer come out to fix it while the second statement allows
> the QA person to make the fix.

Hi Jim,

interesting.  I was thinking about #1 — I can make a coffee, I can cancel making it, you can make a coffee, but you can’t cancel my coffee.
Or delete my RD entry, etc.  So making the resource confers ownership (really: a separate set of permission bits) that is bound to the subject.

In my view of how permission systems usually work, the other alternative requires creating a group.  The inherited permission would then be attached to the group.
Since AIF is about capability lists, not about subject identities, I think we are covered — just have the capability list on the group.

NFSv4 permissions probably also have a way to handle this kind of inheritance, but I’ll not have time to look that up today...

Grüße, Carsten