> But it seems to me that conceptually what happens at the *assign* > operation is much more of an *ownership* change for a file. > Thus before the assignment, changes to bge3 require the PRIV_MUMBLE and > being in the global zone. After the assignment to zoneA, changes to bge3 > require PRIV_MUMBLE and being in zoneA. > Only "reset-linkprop -t zoneid" needs to be special in that the global > zone can do this (as long as zoneA isn't currently using the link.) > > In this "ownership" model it naturally falls out that only the owner of > a link can use that to create aggregations, VLANs, etc.
Yes, that makes sense to me. > That seems a bit different than the name space approach David was > suggesting. As I understand that model the global zone would still see > the link (with e.g. a "zoneA-bge3" name) but that doesn't inherently say > whether the global zone can modify properties for that link name, nor > whether it can use the link name to construct aggregations or VLANs. > > I don't know what factors and considerations I'm missing, so feel free > to enlighten me. It's not clear to me if you're agreeing or disagreeing with the idea of the "namespace manipulations", but I think they're necessary to address other problems. For instance, without its own private link namespace (or carved-out part of the global link namespace), there is no way for the local zone to be sure that it will be able to create a link with a given name at any point in time. DR is another generally thorny issue when it comes to links in zones. Seems like one would have to shut down all of the zones using links above a given device in order to DR that device out of the system, which is unfortunate. But fixing that would probably require a pretty big overhaul of the way DR works (maybe to be modeled as a "link down" operation, as we'd discussed a while ago). -- meem
