Yifan Xu wrote:
> 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.
I think there is no way you can anticipate needs for
every services. So maybe you can assume that a service
requiring VRRP support will do the right thing and
assign a correct rights profile to the executable. Then
you do not need to worry about that.
> 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.
I guess you don't want to allow any user to put executable
under /etc/vrrpd/. It is not world writable, right?
> 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.
I think you misunderstood the example I used. The example
does not require vrrpd to provide an IPC notification. The
vrrpd just runs an executable provided by the service
developer. And that executable will use the service's own
IPC mechanism to talk to the service. This does not require
any modification to the current proposal. This is the point
I tried to raise. There is no need for vrrpd to be run by
root.
--
K. Poon.
[EMAIL PROTECTED]
_______________________________________________
networking-discuss mailing list
[email protected]
