On (05/12/10 14:43), Darren Reed wrote:
>
> What is done to ensure the alignment of "allowed-ips" and the
> addresses configured?
We've already had extensive internal discussions about this, but
let me reiterate..
I don't know what you mean by "alignment", but as Erik explained to you
"Today if you set allowed-ips with dladm and then use ifconfig/ipadm to
set the IP address to something which is not in allowed-ips, then the
system silently drops all your sent packets on the floor.
With this proposal instead the SIOCSLIFADDR ioctl will fail, so ifconfig
and ipadm can report that failure to the admin."
> If I change the "allowed-ips" directly with dladm after a zone
> has booted, will there be any warning?
No, you would only be able to do this from the Global Zone, and the
assumption is that the GZ is the authoritative source of configuration,
so if that's the choice made in the GZ, nothing will prevent this.
> If I want to change the IP address of a network interface in a
> zone that is so restricted, what is the correct procedure?
you would have to do the same thing that you do for shared IP today-
the GZ would have to change zonecfg and the change would be picked
up on the next reboot.
> At the top, it states that if the global zone configures the address
> for a network interface then the local zone is not permitted to
> change it. Why should that have anything to do with forwarding?
> Is the right approach being taken here? This would appear to
> be a security issue (revoking the right of a zone to make a change
> to its network configuration) but yet the implementation of the
> support for this does not make use of any security fundamentals.
> Why not?
In internal discussions, it was my understanding that *you* had expressed
the objection that setting allowed-ips on the interface would, in effect,
prevent the NGZ from forwarding out of that interface, and that this
behavior would happen without warning. Also in internal discussions
many of us have repeatedly explained to you that this is the
case where we want to simplify the simple network configuration case
using the same techniques that are already familiar to shared-IP users.
Thus, as Michael Hunter observed, to look at this as a "pure
configuration" or "pure security" solution is misleading.
> At the bottom of this document, the man page update mentions
> that this feature is incompatible with enabling forwarding. Why?
> Shouldn't we be engineering Solaris to make features compatible
> with each other rather than incompatible?
This feature does not introduce any feature incompatibility. It merely
makes the error semantics explicit.
> I'm uncomfortable with this because it increases the complexity
> of the interaction with GLD and IP for questionable gain. My
> view of this is that it is an attempt to make up for the lack
> of proper architecture whereby networking resources for a zone
> are supplied, set and applied.
:
> If, for example, I wanted to extend this work to supply other layer-3
> network properties, how would I do that? Implement a new mechanism
> for each one? Does that really scale?
>
> My concern here is that given a problem that would have future benefit
> from real architecture being developed, the solution that we're being
> given is a few hacks to solve specific problems.
perhaps we should just agree to disagree, because from the numerous
internal discussions, I don't think your opinion is shared by a majority.
--Sowmini
_______________________________________________
opensolaris-arc mailing list
[email protected]
