Subject: [Ace] Extended REST model comment

From: Jim Schaad <[email-masked]>
Date: Tue, 30 Jun 2020 07:43:20 -0700

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.

Jim

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 30 Jun 2020 17:35:22 +0200

> 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

---

From: Jim Schaad <[email-masked]>
Date: Tue, 30 Jun 2020 12:23:46 -0700

> -----Original Message-----
> From: Carsten Bormann <[email-masked]>
> Sent: Tuesday, June 30, 2020 8:35 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Ace] Extended REST model comment
> 
> > 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.

[JLS] I would agree that there is no need to make any changes in the AIF structure.  I would just like to see some text discussing that policy can enforce this in either way.

Jim

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