>Number:         9954
>Category:       misc
>Synopsis:       rc.d system is missing one of my wish-list items
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    misc-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Apr 22 04:56:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Dave Sainty
>Release:        Recent current
>Organization:
Dynamic Technology Services and Products Ltd (NZ)
>Environment:
System: NetBSD tequila.dave.dtsp.co.nz 1.4R NetBSD 1.4R (TEQUILA) #3: Wed Feb 16 20:01:31 NZDT 2000 dave@tequila.dave.dtsp.co.nz:/vol/tequila/userB/u2/NetBSD-current/src/sys/arch/i386/compile/TEQUILA i386


>Description:
	I run some of my system services (for example 'xfs') as specific
	non-root users.  For example, xfs runs as the user 'xfs', which is a
	member of the group 'xfs'.  The 'xfs' group has write access to
	'/var/log/fs-errors', the xfs error log.  Other services may run as
	'nobody' if they require no special file-system access.

	rc.d tends to run things as root instead.

>How-To-Repeat:
	Inspection.

>Fix:
	I propose that /etc/rc_subr:run_rc_command() be extended to pay
	attention to '${name}_user'.  If it is set, the command should be run
	with:

	echo "$command $_flags $command_args" | su -m $_user

	However, this opens up a second issue, that the daemon will no longer
	be able to dump core arbitrarily (usually the root directory).  So I
	also propose that the '${name}_chdir' variable be used to change
	directory before execution, to a core-friendly directory (in my case
	'/var/cores').

	echo "${_chdir+cd $_chdir;}$command $_flags $command_args" | su -m $_user

	Variations on the theme may see each rc.d script setting a default
	user if root is not required.  Especially where 'nobody' is ok.  Also,
	perhaps su'ing before delivering signals would be a bonus, as a
	protection against incorrect pid file contents.  Killing as user 'xfs'
	is guaranteed safe (only one program is run as xfs), killing as 'root'
	is always risky.

	The changes are fairly mechanical (depending on what should and
	shouldn't be implemented), but I'll happily provide a patch on
	request if changes are agreed on.
>Release-Note:
>Audit-Trail:
>Unformatted: