On 2020-06-30, at 16:43, Jim Schaad <[email protected]> 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 _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
