Liane, Thanks for your extensive explanation. I hope it could also be covered in some well-known documents, like the ARC SMF Policy.
Riny Liane Praza wrote: > Riny Qian writes: > >>Hi, >> >>I noticed there are a lot of SMF manifests (e.g. auditd.xml, >>cron.xml, dbus.xml, hal.xml), which include the following >>method_context for exec_method: >> >> <method_context> >> <method_credential user='root' group='root' /> >> </method_context> >> >>Is it really needed? Since the service is started by svc.startd(1M), >>the method_context will be set to such (e.g. user='root') by default. > > > That's true. It isn't strictly needed as svc.startd launches > services and legacy services as root. We did this to preserve > compatibility with old init.d behaviour, and to make sure that > folks who aren't bound by the ARCs additional requirements on manifest > construction can create services that generally work without having > to specify a bunch of extra execution context information. > > I believe the initial service authors who started this convention did > so in order to explicitly state their service's requirements rather > than rely on default behaviour of the restarter. > > Explicitly stating your service's requirements in the manifest is always > a good way to go, so I belive this is good practice. It isn't practice > I'd explicitly enforce, though. (Do note that the ARCs require that > services are configured to run with the least possible privileges. But, > if root/root is the least possible privilege for a service, I personally > woudln't insist on the declaration.) > > Tangentially... > > Another example of explicitly stating requirements rather than relying on > implicit behaviour is with dependencies. A well written service will > explicitly depend on everything it requires. Some clever service authors > have said "oh, but I already depend on system/system-log, and it depends on > filesystem/local. Why should I put an explicit dependency on > filesystem/local?". While that seems appropriate today, it doesn't actually > bring any run-time benefit for performance and could possibly break in > the future. Stating dependencies explicitly allows someone re-factoring > the dependencies in the future (or exploring dependencies to understand > the service better today) to tell that you explicitly rely on > filesystem/local. > > liane
