Kacheong Poon wrote:
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.
That question is actually the concern. Can we assume network
configuration privileges are sufficient for reasonable actions to
be registered? If not, what else privileges should be added to
vrrpd? As you can see I didn't get to find a better example than
the forwarding knob, which still falls in the networking privilege
set.
But there is another issue for not using root. Users who has
insufficient networking privileges are still able to put executables
in /etc/vrrpd/ to be executed by vrrpd.
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?
It is not an issue for future services who want to exploit
vrrp notification. What I mean is such an interface would
disable existing service/program from being utilized
without any modification, if the vrrpd only provide an
IPC notification scheme.
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.
Understood. I think we need to chew on it a bit more.
Yifan
_______________________________________________
networking-discuss mailing list
[email protected]
