On 08/11/09 15:14, Sebastien Roy wrote:
> 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).
That should work.
> 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.
ok.
>
>> 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.
understood.
~Girish
