Yifan Xu wrote:
> This scheme should work without requiring vrrpd to run as
> root. But there are some limitations. It implies that only
> services that run as a daemon could utilize the notification.
> For example, if an administrator wanted to enable forwarding
> only when the VRRP turns into master state, an executable is
> required to do "svcadm enable/disable ipv4-forwarding" or
> "ndd -set /dev/ip ip_forwarding 1/0".
Have you checked out RBAC and see if it can help here?
BTW, vrrpd should already have enough network configuration
privileges. Is it safe to assume that these privileges are
enough for all network configuration related services which
may make use of VRRP? Then the executable does not need
to run by root and have all privileges.
> Another requirement
> for this scheme is the services should be aware of the
> notification interface and make some changes to exploit it.
I don't understand. Who will provide the notification
executable? I think the service developer who wants to
make use of this mechanism will provide it. And I think
the developer will need to know about this interface in
order to use it. What is the extra requirement?
> To make it flexible and easy to use we prefer the simple
> solution of raising the security threshold to allow all kinds
> of actions, because privileges required for various executions
> are unpredictable. Opinions?
So this is the traditional all-or-nothing security model.
I think Solaris has moved beyond this for quite some time.
I suspect that you need stronger justification to go back
in time for new service.
--
K. Poon.
[EMAIL PROTECTED]
_______________________________________________
networking-discuss mailing list
[email protected]
