[OpenIndiana-discuss] Problem running rsync with smf service

[James Carlson]

On 12/07/12 15:19, steve at linuxsuite.org wrote:
> root at live-dfs-1:/var/adm# diff /lib/svc/method/rsyncd
> /home/steve/rsyncd-smf
> 53c53
> <                sudo -u nobody $DAEMON --daemon
> --config="$RSYNC_CONFIG_FILE" $RSYNC_OPTS
> ---
>>                $DAEMON --daemon --config="$RSYNC_CONFIG_FILE" $RSYNC_OPTS

I'll assume that you've added "sudo -u nobody" to the invocation line in
the script.  (Why "sudo" and not "su" ... ?)

That doesn't really look like SMF to me.  Instead, I would have expected
that instead of modifying the script at all, you'd change the
method_credential for the exec_method on this service.  Something like this:

# svccfg -s rsyncd
svc:/network/rsyncd> select default
svc:/network/rsyncd:default> setprop start/user = "nobody"
svc:/network/rsyncd:default> refresh

Of course, I'm not sure that's really the right thing to be doing here
anyway, as "nobody" is a special user for the file system (particularly
for NFS user mapping), and having processes running as "nobody" is
something I'd expect the system designers to call A Very Bad Idea.  I
believe that "daemon" was really intended for this purpose instead.
(But with Least Privilege, the user ID doesn't matter nearly as much as
you might otherwise think it does.  Even running as UID "root" doesn't
mean that you're all-powerful.  Only the credentials you have give you
power on Solaris.)

If your actual goal here is to limit the risk of running rsyncd, you
should probably read up on Least Privilege (start with the privileges(5)
man page) and SMF (start with smf(5)).  Changing the start-up script is
at best a hack.

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>