> As for the latter one, I don't really have much choice in the matter, > as the in.ndpd->dhcpagent->eventhook chain doesn't really allow for > much control in privilege escalation. The best I could muster would > be modifying the code itself to bracket privilege around the > operations that need it (invoking dhcpagent via in.ndpd and perhaps > dhcpagent's invocation of eventhook), but that solution seems a lot > less good than the bigger (and out-of-scope) change of converting DHCP > itself into a service and getting rid of the direct fork-and-exec from > libdhcpagent.
just a note to say i've been taking a look to see what would be required to provide an SMF serivce conversion for dhcpagent. as far as i can see it's pretty straightforward - just a case of providing manifest/method, changing fork/exec of dhcpagent in libdhcpagent to a call to smf_enable_instance() (temporary enable), and updating the service method for network/physical to use "svcadm enable -t dhcp-agent" as opposed to running /sbin/dhcpagent directly. as well as taking care of the privilege issue mentioned above, this would also solve the issue with the stop method of the "ndp" service - the :kill run there will also take out the dhcpagent process and any eventhook scripts launched by it, since these are in the same contract as in.ndpd. anyway i'll file an RFE on this soon, just wanted to give a head's up. thanks! alan This message posted from opensolaris.org _______________________________________________ networking-discuss mailing list [email protected]
