Cathy Zhou wrote: > I ran into a problem with the VRRP project which I am working on. In > particular, The vrrpd daemon was ran by the vrrp:default service, and > its privileges is defined in vrrp.xml like below: > > <method_context> > <!-- > We need PRIV_SYS_CONFIG to post VRRP sysevent, > PRIV_NET_ICMPACCESS and PRIV_NET_RAWACCESS to > open the raw socket, PRIV_SYS_IP_CONFIG to bring > up/down the virtual IP addresses. > --> > <method_credential > user='root' > group='root' > limit_privileges=':default' > > privileges='basic,sys_config,net_icmpaccess,net_rawaccess,sys_ip_config' > /> > </method_context> > > Note that the vrrp service can be run in both global zone and non-global > exclusive IP zone. But apparently, sys_config is not able to be set in > an non-global zone, or "svcadm enable vrrp" would fail with "svc.startd > could not set context for method: ] setppriv: Not owner" failure. > > It is fine to not specify the sys_config privilege in the non-global > zone (as we only need this privilege for posting sysevent and sysevent > is not supported in the non-global zone anyway), but my question is: > > How to specify different privileges requirement for the same service in > different zones? Or should I have to *not* specifying the privileges in > the xml file, but instead to drop and limit the privileges in the vrrpd > daemon itself?
This has come up before, unfortunately I don't think we ever came up with a good solution for it. There isn't a fixed set of privileges associated with a zone, so letting the service developer have a "global zone set" and a "non-global zone set" doesn't solve the problem: the non-global might work on one system (or zone), and might fail for another. We could use a token for "all the privileges we have", from which you could subtract the privileges you don't want, but that is tedious and doesn't weather well as new privileges are added to the system. The most reasonable (and simplest) solution would simply be to give the service the intersection of the privileges available to the zone and the privileges requested and generate an informative log message if the service is being started with less than the requested set of privileges. In the absence of a change to SMF, the only solution would be to start the service with all privileges and drop the ones you don't after it starts. If you're integrating in ON, I'd recommend just fixing SMF; the change should be simple and less overall work than implementing it in your service. Dave
