Self-service constraints when combined with ACLs
-
This is a follow up question to the one I posted on ACL inheritance for network objects.. Essentially, when building a self-service resource set, it isn't obvious whether the included resource set is supposed to override any ACLs, or work in tandem.
For example, if I grant "viewer" rights to the pool, why do I need to provide a set of read-only templates, read-only networks, and read-only SRs? It seems to me that the ACLs should take care of that, and the SS should cover anything I need to provide additional operator or admin rights [i.e. read/write SRs, etc.] (in fact, I don't even know what rights the SS resource set actually confers -- is it admin/operator/something else?)
I feel like I have a fundamental misunderstanding of ACLs and SS. Coming from vSphere, I am trying to emulate an inherited DAC permission model, but the XO ACLs seem too limited (I think having an explicit "deny" ACL would dramatically help here by allowing permission "hole-punching"), and the SS isn't dynamic enough.
Can someone help shed some light on how ACLs and SS work together, if at all?
-
O olympicgreg marked this topic as a question
-
You should have kept on thread, it's easier to track. Anyway, another ping to @pdonias
