[developer] Review - 16806 Some services unexpectedly start in /root

[developer] Review - 16806 Some services unexpectedly start in /root

[Andy Fiddaman]

I've been looking into why some daemons are running with the working directory
set to /root, for example:

        bloody% fuser /root
        /root:      516c     467c     364c     322c     320c
        bloody% ps -p 516,467,364,322,320
          PID TTY         TIME CMD
          320 ?           0:00 pfexecd
          322 ?           0:00 zonestat
          364 console     0:00 ttymon
          467 ?           0:00 rpcbind
          516 ?           0:50 zrepl

but not all:

        bloody% pfexec pwdx `pgrep utmpd`
        359:    /

This turns out to be due to something that I couldn't find documented in the
manual. By default, SMF will start a service using the old `init` defaults
of UID/GID 0 and in /. However, if the SMF method has a non-empty
<method_context/>, then it will start it with the smf_method(7) defaults
of UID/GID 0, in UID 0's home directory (typically /root), having explicitly
set the privilege limit set to `zone`, etc. Obviously if the <method_context/>
overrides any of these then those values are used instead.

I think this is a bit of a gotcha. `zrepl', for example, uses a
<method_context> to enable ASLR and falls foul of this as you can see in the
process list above.

        <exec_method type='method' name='start'
                     exec='/lib/svc/method/zrepl start %{config/file}'
                     timeout_seconds='60'>
            <method_context security_flags='aslr' />
        </exec_method>

I went back and forth on a way to improve the situation here and reduce the
surprise factor and have so far settled on the following:

- As now, if there's no <method_context/> use the old init defaults;
- if there is a <method_context/> but it does not specify uid, gid or
  working directory, use the smf_method(7) defaults but explicitly reset the
  start directory to /;
- update the smf_method(7) man page.

This assumes that anyone who adds a <method_context><method_credential> knows
what they're doing and expects to start in the specified user's home directory.
For several services in gate, this meant that I have had to go through and
add an explicit working_directory attribute to the <method_context/> to get
it to start in /.

There are a number of services, like svc:/system/hal which define a
<method_context/> that could probably just be removed:

        <exec_method type='method' name='start'
                exec='/lib/svc/method/svc-hal start'
                timeout_seconds='600'>
                <method_context>
                        <method_credential user='root' group='root' />
                </method_context>
        </exec_method>

I have elected NOT to do that in this change because the resulting start
context would be subtly different without that element there. hald, like
many daemons does a chdir("/") early, but it would still be better for SMF
to start it in / -- one of drivers for this change is to more easily allow
/root to be a separate ZFS dataset.

With all that said, here's the change so far. Please can you take a look?

    16806 Some services unexpectedly start in /root
    https://www.illumos.org/issues/16806
    https://code.illumos.org/c/illumos-gate/+/3720

Thanks,

Andy

------------------------------------------
illumos: illumos-developer
Permalink: https://illumos.topicbox.com/groups/developer/Tb9d9cd4ce7feca04-M282a14adec97c116c82111a3
Delivery options: https://illumos.topicbox.com/groups/developer/subscription