Bug 235791

Summary:	service(8) does not respect login.conf
Product:	Base System	Reporter:	Andrew "RhodiumToad" Gierth <andrew>
Component:	bin	Assignee:	freebsd-rc (Nobody) <rc>
Status:	Closed FIXED
Severity:	Affects Some People	CC:	dteske, jamie, kevans, rgrimes, sigsys
Priority:	---
Version:	11.2-STABLE
Hardware:	Any
OS:	Any
See Also:	https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235185

Description Andrew "RhodiumToad" Gierth 2019-02-17 01:40:30 UTC

service(8) sets an empty environment via env -i when invoking rc.d files.

This is wrong, because it's not the same environment that init provides, which comes from the "daemon" login class in login.conf.

The practical upshot of this is that there is no way (short of modifying the scripts) to set environment variables that rc.d scripts might need, such as an HTTP_PROXY setting to allow "service ntpd onefetch" to work on a system behind a proxy.

Related but possibly less serious: when rc.subr invokes a command under a specified login class, it sets only the resource limits and not the environment.

To reproduce:

add HTTP_PROXY=http\c//yourproxyhost\cport/  to the setenv= property of "default" or "daemon" in login.conf

then observe (from a host with no public connectivity)

# service ntpd onefetch
fetch: https://www.ietf.org/timezones/data/leap-seconds.list: Network is unreachable

Comment 1 Kyle Evans freebsd_committer

2019-02-17 01:45:01 UTC

CC'ing dteske@ and assigning to rc@

Comment 2 Rodney W. Grimes freebsd_committer

2019-02-17 15:59:49 UTC

(In reply to Kyle Evans from comment #1)
Kyle, Devin,
Is this not in line with the similiar issue we are seeing about starting /etc/rc.d/* scripts from the command directly, rather than using the service(8) command?  This was discussed heavily in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235185.

Comment 3 Andrew "RhodiumToad" Gierth 2019-09-03 20:04:26 UTC

The start of a concrete proposal to address this is here: https://reviews.freebsd.org/D21481

Comment 4 Andrew "RhodiumToad" Gierth 2020-03-30 02:44:31 UTC

Closing FIXED since the linked review was committed some weeks back, albeit only to CURRENT.