[apple/mdnsresponder.git] / mDNSMacOSX / README.privsep

On Mac OS X, mDNSResponder now runs with user-ID and group-ID
"_mdnsresponder". In order to perform certain privileged operations, a
helper (unimagintively called mDNSResponderHelper) runs as root when
needed and handles requests from mDNSResponder.


* A new LaunchD job com.apple.mDNSResponderHelper starts
  mDNSResponderHelper on demand.  The helper exits after approximately
  10 seconds of idle time.

* The com.apple.mDNSResponder LaunchD job specifies the account under
  which to run, so that mDNSResponder starts as _mdnsresponder.

* A subdirectory named "mdns" and owned by _mdnsresponder has been
  created in /var/run.  The PID file and uDNS server socket has been
  moved to that subdirectory.

* There are currently six remote procedure calls handled by
  mDNSResponderHelper: mDNSPreferencesSetName, mDNSKeychainGetSecrets,
  mDNSConfigureServer, and mDNSAutoTunnelSetKeys

* mDNSPreferencesSetName allows mDNSResponder to set the computer name
  or local host name, and displays a notification if there was a
  conflict.

* mDNSKeychainGetSecrets causes mDNSResponderHelper to collect DNS
  keys from the system keychain.  SetDomainSecrets uses the result to
  populate AuthInfoList.  One could refactor this code further so that
  mDNSResponderHelper performs all the cryptographic operations, with
  the result that a compromise of mDNSResponder does not compromise
  keys.  But I think that may be more change than is advisable at this
  point.

* On the advice of the Security.framework team, I've used
  SecKeychainSetPreferenceDomain to ensure that the system keychain is
  references whenever a NULL SecKeychainRef is used.  Wherever a
  SecKeychainRef is needed, NULL is now specified.

* mDNSConfigureServer, and mDNSAutoTunnelSetKeys do various setup and
  teardown for BTMM.
Commit	Line	Data
67c8f8a1 A	1	On Mac OS X, mDNSResponder now runs with user-ID and group-ID
	2	"_mdnsresponder". In order to perform certain privileged operations, a
	3	helper (unimagintively called mDNSResponderHelper) runs as root when
	4	needed and handles requests from mDNSResponder.
	5
	6
	7	* A new LaunchD job com.apple.mDNSResponderHelper starts
	8	mDNSResponderHelper on demand. The helper exits after approximately
	9	10 seconds of idle time.
	10
	11	* The com.apple.mDNSResponder LaunchD job specifies the account under
51601d48	12	which to run, so that mDNSResponder starts as _mdnsresponder.
67c8f8a1 A	13
	14	* A subdirectory named "mdns" and owned by _mdnsresponder has been
	15	created in /var/run. The PID file and uDNS server socket has been
	16	moved to that subdirectory.
	17
	18	* There are currently six remote procedure calls handled by
51601d48	19	mDNSResponderHelper: mDNSPreferencesSetName, mDNSKeychainGetSecrets,
83fb1e36	20	mDNSConfigureServer, and mDNSAutoTunnelSetKeys
67c8f8a1	21
67c8f8a1 A	22	* mDNSPreferencesSetName allows mDNSResponder to set the computer name
	23	or local host name, and displays a notification if there was a
	24	conflict.
	25
	26	* mDNSKeychainGetSecrets causes mDNSResponderHelper to collect DNS
	27	keys from the system keychain. SetDomainSecrets uses the result to
	28	populate AuthInfoList. One could refactor this code further so that
	29	mDNSResponderHelper performs all the cryptographic operations, with
	30	the result that a compromise of mDNSResponder does not compromise
	31	keys. But I think that may be more change than is advisable at this
	32	point.
	33
	34	* On the advice of the Security.framework team, I've used
	35	SecKeychainSetPreferenceDomain to ensure that the system keychain is
	36	references whenever a NULL SecKeychainRef is used. Wherever a
	37	SecKeychainRef is needed, NULL is now specified.
	38
83fb1e36 A	39	* mDNSConfigureServer, and mDNSAutoTunnelSetKeys do various setup and
83fb1e36 A	40	teardown for BTMM.