@pdonias
Thanks for the reply and clarification on this.

In our environment, we are a test environment, so we are constantly spinning up VMs on isolated networks segregated by VLANs. We have admins and we have users. Users can make VMs and make use of pretty much all the resources, but they can't create or config resources (so they pretty much have "operator" access).
However, there are resources I don't want users to have access to -- or even see even if the user is granted rights higher up in the hierarchy. I would like to see the idea of an ACL "deny" which basically punches a negative access hole in the ACL hierarchical resolution.
I foresee myself mostly using the ACLs instead of the self-service set because of how we operate and because the ACLs are more transparent and (more) dynamically adjusting (i.e. using hierarchical resolution). Coming from a VMware world, the ACL model make more sense to me and I would be able to more easily map my current permission model.
It might be nice to assign ACLs based on tags (or containers) as well. This would allow me to place certain resources into those containers/tag groups and assign ACLs based on them without considering each individual object.
In the ACL screen, right now the ACLs are individually shown. This is very noisy when you have lots of ACLs and it is hard to get a picture of the permission model. I think a reorg of how the ACL information is presented is needed to help make informed authorization decisions.

@splastunov I realize this thread is old, but I think there is important info to keep connected to this thread for future readers.

The IP locking trick doesn't seem to prevent all traffic -- it only prevents traffic that has an IP that isn't 255.255.255.255 (and possibly others as well). That is, I can still successfully acquire a DHCP IP even when the IP locking mechanism is engaged. I think this is important for others to know since it doesn't fully isolate VMs like the OP wanted.

UPDATE: Setting the locking mode to "disabled" is what you want -- not "locked". Disabled will drop all traffic; locked simply checks if the set of IPs in the VM is permitted. Source: https://docs.xenserver.com/en-us/citrix-hypervisor/networking/manage.html#vif-locking-mode-states

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?

I've been trying to understand the interactions between ACLs and self-service on XO and it seems somewhat inconsistent for Networks.

I have granted a set of users "viewer" access to the entire pool. I have also constructed a self-service set (I have a different question on the self-service restrictions I will post shortly). However, within the self-service set, unless I provide all of the networks in the self-service set, the user is not able to see the network when building a VM.

In our environment, we build/remove networks via VLANs constantly. Having to go into the self-service set to add/remove these networks is not ideal. I would have thought that the inheritance of the networks via the "viewer" ACL would have been enough. Is this not the case?

I see in the XO docs for ACLs that the inheritance says "pools > hosts > VMs". I thought this was an example (i.e. there are other examples that discuss the operations on VMs as a case-study), but perhaps this is the only inheritance path. Is there a reason that networks might not be included in this model (or for that matter, if "pool" is given "viewer", why can't a user see everything in the pool)?