Girish,
Thanks for the review.
On Tue, 2009-08-11 at 14:26 -0400, Girish Moodalbail wrote:
> Questions:
> ------------
> Do we use following environment variables defined in
> /etc/default/inetinit (this is called in from net-init)
>
> ACCEPT6TO4RELAY=NO
> RELAY6TO4ADDR="192.88.99.1"
>
> I didn't see them either in net-init or net-iptun. Though @ L73 of
> net-init I see reference to those variables in 'comments'. Can we get
> rid of those variables altogether from /etc/default/inetinit, if we are
> not using it.
They should be used by an SMF method to call the 6to4relay command with
the appropriate options. Something is indeed broken (both in Nevada and
in the Clearview gate) regarding these variables. The net-routing-setup
script seems to be calling 6to4relay, but that makes no sense given that
net-routing-setup has nothing to do with 6to4 tunneling or tunnel
configuration at all, and it doesn't load the variables from inetinit...
The configuration of these variables is document in the Solaris admin
guide, and it's the only way to persistently configure 6to4 relay
operation. What I will do is have the net-iptun script source inetinit
and call 6to4relay directly (i.e., move the code from net-routing-setup
to net-iptun). Really, these should be moved to SMF properties, but
that can be done separately.
> usr/src/cmd/svc/milestone/Makefile
> ---------------------------------
> @L45: Is it possible to order these services in the order they come up.
> It will be very helpful for people who want to understand in what order
> these network services come up. Unfortunately, today the only place you
> would know the order is in "comments" section of net-init.
There is no sequential order since SMF has a dependency graph that
doesn't require a set of services to be started in sequence. For
example, network/initial depends on milestone/network, and network/iptun
depends on network/physical, but there's no explicit dependency between
network/initial and network/iptun. The SMF dependency graph shouldn't
be represented in Makefiles, but rather in the SMF manifests themselves.
>
> usr/src/uts/common/os/policy.c
> -------------------------------
>
> L1739-1747, I guess, could be simply re-written to
>
> int
> secpolicy_iptun_config(const cred_t *cr)
> {
> if (secpolicy_dl_config(cr) != 0)
> return (PRIV_POLICY(cr, PRIV_SYS_IPTUN_CONFIG, B_FALSE,
> EPERM, NULL));
> return (0);
> }
We don't want to call secpolicy_dl_config() directly like that because
it gets audited on failure, and such a failure does not indicate that
the caller didn't have the sys_iptun_config privilege. That's why there
are calls to PRIV_POLICY_ONLY() to do the check without the audit trail,
and then do the real secpolicy_*() call where it matters and where we
want the audit record to be generated.
>
> usr/src/lib/libdlpi/common/libdlpi.c.. OK
> usr/src/lib/libdlpi/common/libdlpi_impl.h.. OK
Thanks!
-Seb
