Re: svn commit: r268641 - head/usr.sbin/service
On Tue, Jul 15, 2014 at 07:48:46PM -0700, dte...@freebsd.org wrote: -Original Message- From: owner-src-committ...@freebsd.org [mailto:owner-src- committ...@freebsd.org] On Behalf Of Mateusz Guzik Sent: Tuesday, July 15, 2014 12:16 PM Indeed, the whole point is to NOT inherit anything from calling process. If that were the point, then we have an issue. Because as it stands, service(8) does _not_ accurately provide the same environment as boot. Take the following boot script: dte...@scribe9.vicor.com ~ $ cat /etc/rc.d/foo #!/bin/sh # PROVIDE: foo set /tmp/termtest . /etc/rc.subr name=foo rcvar=foo_enable command=/usr/local/bin/tmux foo_flags=new -s foo ls load_rc_config $name run_rc_command $1 Now reboot to find the following in /tmp/termtest: [snip] Compare that with the following: dte...@scribe9.vicor.com ~ $ sr service foo start dte...@scribe9.vicor.com ~ $ cat /tmp/termtest HOME=/ IFS=' ' OPTIND=1 PATH=/sbin:/bin:/usr/sbin:/usr/bin PPID=1285 PS1='# ' PS2=' ' PS4='+ ' PWD=/ Looks to me like some things are being inherited. Notably, it would appear that the rc.d scripts are run within the parent namespace which has had source_rc_confs() called (I'm leaving alone for the moment that this indicates that each rc-script is being less than efficient by re-sourcing rc.subr). Well, let me be more specific: the point is to not inherit random stuff which happens to be in the environment so that it does not end up in an environment of the new process. With than in mind here is an environment from something which was executed, not rc.d script itself: HOME=/ IFS=' ' OPTIND=1 PATH=/sbin:/bin:/usr/sbin:/usr/bin PPID=802 PS1='# ' PS2=' ' PS4='+ ' PWD=/ RC_PID=18 Which pretty much matches 'service foo start' invocation by hand. Although RC_PID seems spurious. Given the above (that we are farther from a clean environment than one might expect), is it really that big of a deal to expose $TERM? If so, what are the serious issues that could arise? I personally cannot think of any shortcomings or fallout from adding $TERM to be exposed. It does not make things work on boot, so you can expect people to complain about it. As was noted elsewhere, this is a change to the runtime which is not needed for most. In best case it is a noop, in worst it breaks things. It is best to not introduce differences when they are not needed It seems the easiest thing would be to have this whole business restricted to custom scripts dealing with tmux. Error message could be improved to note TERM was not set. Maybe a tmux-specific wrapper to run stuff detached should be added to the port? It would take care of settng TERM based on some config. Putting TERM for everyone just because the service happened to be start by hand does not look justifiable. -- Mateusz Guzik mjguzik gmail.com ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r268641 - head/usr.sbin/service
On 16 Jul 2014, at 14:49, Adrian Chadd adr...@freebsd.org wrote: On 15 July 2014 22:08, Mark Linimon lini...@lonesome.com wrote: On Tue, Jul 15, 2014 at 07:13:44PM -0700, dte...@freebsd.org wrote: destroying all vestiges of that environment purely for the sake of saying it's clean seems counter to the UNIX pathos. I think you mean ethos here, but frankly I like it better this way. I'm a bit confused by this thread. screen and tmux are interactive processes. They're not designed to be run as UNIX services. Why is this even happening? The mine craft server port uses tmux so you can fiddle with the MC console later. Neither screen nor tmux cares if TERM is set when it is run, e.g. [midget 18:25] ~ env -i /usr/local/bin/tmux new-session -d [midget 18:25] ~ tmux ls 0: 1 windows (created Wed Jul 16 18:25:33 2014) [241x38] [midget 18:26] ~ env -i /usr/local/bin/screen -d -m [midget 18:26] ~ screen -ls There are screens on: 30081..midget (Detached) 3 Sockets in /tmp/screens/S-darius. Regards, Daniel O’Connor ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
RE: svn commit: r268641 - head/usr.sbin/service
-Original Message- From: owner-src-committ...@freebsd.org [mailto:owner-src- committ...@freebsd.org] On Behalf Of O'Connor, Daniel Sent: Wednesday, July 16, 2014 1:58 AM To: Adrian Chadd Cc: Mark Linimon; Mateusz Guzik; svn-src-all@freebsd.org; Bryan Drewery; src-committ...@freebsd.org; svn-src-h...@freebsd.org; Devin Teske Subject: Re: svn commit: r268641 - head/usr.sbin/service On 16 Jul 2014, at 14:49, Adrian Chadd adr...@freebsd.org wrote: On 15 July 2014 22:08, Mark Linimon lini...@lonesome.com wrote: On Tue, Jul 15, 2014 at 07:13:44PM -0700, dte...@freebsd.org wrote: destroying all vestiges of that environment purely for the sake of saying it's clean seems counter to the UNIX pathos. I think you mean ethos here, but frankly I like it better this way. I'm a bit confused by this thread. screen and tmux are interactive processes. They're not designed to be run as UNIX services. Why is this even happening? The mine craft server port uses tmux so you can fiddle with the MC console later. Neither screen nor tmux cares if TERM is set when it is run, e.g. [midget 18:25] ~ env -i /usr/local/bin/tmux new-session -d [midget 18:25] ~ tmux ls 0: 1 windows (created Wed Jul 16 18:25:33 2014) [241x38] [midget 18:26] ~ env -i /usr/local/bin/screen -d -m [midget 18:26] ~ screen -ls There are screens on: 30081..midget (Detached) 3 Sockets in /tmp/screens/S-darius. Looks like -d is the magic that needs to be used in rc.d scripts. Thanks! I'll start spreading that knowledge and reverse r268641. -- Devin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
RE: svn commit: r268641 - head/usr.sbin/service
-Original Message- From: Devin Teske [mailto:de...@shxd.cx] Sent: Wednesday, July 16, 2014 9:20 AM To: 'O'Connor, Daniel'; 'Adrian Chadd' Cc: 'Mark Linimon'; 'Mateusz Guzik'; 'svn-src-all@freebsd.org'; 'Bryan Drewery'; 'src-committ...@freebsd.org'; 'svn-src-h...@freebsd.org'; 'Devin Teske' Subject: RE: svn commit: r268641 - head/usr.sbin/service -Original Message- From: owner-src-committ...@freebsd.org [mailto:owner-src- committ...@freebsd.org] On Behalf Of O'Connor, Daniel Sent: Wednesday, July 16, 2014 1:58 AM To: Adrian Chadd Cc: Mark Linimon; Mateusz Guzik; svn-src-all@freebsd.org; Bryan Drewery; src-committ...@freebsd.org; svn-src-h...@freebsd.org; Devin Teske Subject: Re: svn commit: r268641 - head/usr.sbin/service On 16 Jul 2014, at 14:49, Adrian Chadd adr...@freebsd.org wrote: On 15 July 2014 22:08, Mark Linimon lini...@lonesome.com wrote: On Tue, Jul 15, 2014 at 07:13:44PM -0700, dte...@freebsd.org wrote: destroying all vestiges of that environment purely for the sake of saying it's clean seems counter to the UNIX pathos. I think you mean ethos here, but frankly I like it better this way. I'm a bit confused by this thread. screen and tmux are interactive processes. They're not designed to be run as UNIX services. Why is this even happening? The mine craft server port uses tmux so you can fiddle with the MC console later. Neither screen nor tmux cares if TERM is set when it is run, e.g. [midget 18:25] ~ env -i /usr/local/bin/tmux new-session -d [midget 18:25] ~ tmux ls 0: 1 windows (created Wed Jul 16 18:25:33 2014) [241x38] [midget 18:26] ~ env -i /usr/local/bin/screen -d -m [midget 18:26] ~ screen -ls There are screens on: 30081..midget (Detached) 3 Sockets in /tmp/screens/S-darius. Looks like -d is the magic that needs to be used in rc.d scripts. Thanks! I'll start spreading that knowledge and reverse r268641. Reverted. Thanks much! -- Devin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r268641 - head/usr.sbin/service
On 7/14/2014 9:18 PM, Devin Teske wrote: Author: dteske Date: Tue Jul 15 02:18:55 2014 New Revision: 268641 URL: http://svnweb.freebsd.org/changeset/base/268641 Log: Fix an issue with service(8) where utilities such as screen(1) and tmux(1) would behave differently when utilizing rc-script was invoked manually vs. service(8). The issue being that these utilities require the TERM environ variable to be set and service(8) was not passing it down. Reported by:Michael Dexter edi...@callfortesting.org PR: bin/191869 Reviewed by:allanjude MFC after: 3 days X-MFC-to: stable/10, stable/9 Modified: head/usr.sbin/service/service.sh Modified: head/usr.sbin/service/service.sh == --- head/usr.sbin/service/service.sh Tue Jul 15 01:03:29 2014 (r268640) +++ head/usr.sbin/service/service.sh Tue Jul 15 02:18:55 2014 (r268641) @@ -139,7 +139,7 @@ cd / for dir in /etc/rc.d $local_startup; do if [ -x $dir/$script ]; then [ -n $VERBOSE ] echo $script is located in $dir - exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin $dir/$script $* + exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin TERM=$TERM $dir/$script $* fi done Hm, I'm not sure about this. The behaves differently is exactly the reason for service(8). It runs with a clean environment such as the boot does. Running an rc script without service(8) will give wrong behavior in many scripts that do not match boot-time behavior. As far as I can tell, TERM is not set on boot. So the rc script would also not work on boot. So this change is wrong. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: svn commit: r268641 - head/usr.sbin/service
On Tue, Jul 15, 2014 at 12:59:05PM -0500, Bryan Drewery wrote: On 7/14/2014 9:18 PM, Devin Teske wrote: Author: dteske Date: Tue Jul 15 02:18:55 2014 New Revision: 268641 URL: http://svnweb.freebsd.org/changeset/base/268641 Log: Fix an issue with service(8) where utilities such as screen(1) and tmux(1) would behave differently when utilizing rc-script was invoked manually vs. service(8). The issue being that these utilities require the TERM environ variable to be set and service(8) was not passing it down. Reported by: Michael Dexter edi...@callfortesting.org PR: bin/191869 Reviewed by: allanjude MFC after:3 days X-MFC-to: stable/10, stable/9 Modified: head/usr.sbin/service/service.sh Modified: head/usr.sbin/service/service.sh == --- head/usr.sbin/service/service.shTue Jul 15 01:03:29 2014 (r268640) +++ head/usr.sbin/service/service.shTue Jul 15 02:18:55 2014 (r268641) @@ -139,7 +139,7 @@ cd / for dir in /etc/rc.d $local_startup; do if [ -x $dir/$script ]; then [ -n $VERBOSE ] echo $script is located in $dir - exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin $dir/$script $* + exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin TERM=$TERM $dir/$script $* fi done Hm, I'm not sure about this. The behaves differently is exactly the reason for service(8). It runs with a clean environment such as the boot does. Running an rc script without service(8) will give wrong behavior in many scripts that do not match boot-time behavior. Indeed, the whole point is to NOT inherit anything from calling process. As far as I can tell, TERM is not set on boot. So the rc script would also not work on boot. So this change is wrong. Yes, but maybe there is a sensible default that could be used? Alternatively, one would have to fixup rc scripts using tmux to do what's best for them. Either, the change as it is looks wrong. Please revert for the time being. -- Mateusz Guzik mjguzik gmail.com ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r268641 - head/usr.sbin/service
On Tue, Jul 15, 2014 at 10:13 PM, dte...@freebsd.org wrote: Blatting out the environment feels rude and non-UNIXy. UNIX programs can, and should expect at a minimum to be able to interrogate the environment they are running within -- destroying all vestiges of that environment purely for the sake of saying it's clean seems counter to the UNIX pathos. I'm not sure I can square this sense of non-UNIXy with the long-standing documented behavior of cron to only set SHELL, PATH, LOGNAME, and HOME. Surely cron is Unixy... -Ben ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
RE: svn commit: r268641 - head/usr.sbin/service
From: Benjamin Kaduk [mailto:bjkf...@gmail.com] Sent: Tuesday, July 15, 2014 7:24 PM To: dte...@freebsd.org Cc: Bryan Drewery; svn-src-h...@freebsd.org; svn-src-all@freebsd.org; src-committ...@freebsd.org Subject: Re: svn commit: r268641 - head/usr.sbin/service On Tue, Jul 15, 2014 at 10:13 PM, dte...@freebsd.org mailto:dte...@freebsd.org wrote: Blatting out the environment feels rude and non-UNIXy. UNIX programs can, and should expect at a minimum to be able to interrogate the environment they are running within -- destroying all vestiges of that environment purely for the sake of saying it's clean seems counter to the UNIX pathos. I'm not sure I can square this sense of non-UNIXy with the long-standing documented behavior of cron to only set SHELL, PATH, LOGNAME, and HOME. Surely cron is Unixy... [Devin Teske] Last time I checked, cron did not define the UNIX standard. That is to say, that simply because cron decides to export those exact 4 variables does not mean that all of UNIX should never export any other variable. I define non-UNIXy as chicanery that makes working in a POSIX environment more difficult. In this particular case, the issue is that should I want to find out what type of terminal my *terminal* program is running on, I shouldn't have to fight the system to determine the answer. Rather, the system should (unless it has damn-good reason) freely offer information that divulges what environment the program is running in. I am not making the argument that boot-scripts should have access to every environment variable in the parent namespace, but I am arguing that standard UNIX idioms such as $TERM _should_ be provided (not providing them is imho non-UNIX like). -- Devin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
RE: svn commit: r268641 - head/usr.sbin/service
-Original Message- From: owner-src-committ...@freebsd.org [mailto:owner-src- committ...@freebsd.org] On Behalf Of Mateusz Guzik Sent: Tuesday, July 15, 2014 12:16 PM To: Bryan Drewery Cc: Devin Teske; src-committ...@freebsd.org; svn-src-all@freebsd.org; svn- src-h...@freebsd.org Subject: Re: svn commit: r268641 - head/usr.sbin/service On Tue, Jul 15, 2014 at 12:59:05PM -0500, Bryan Drewery wrote: On 7/14/2014 9:18 PM, Devin Teske wrote: Author: dteske Date: Tue Jul 15 02:18:55 2014 New Revision: 268641 URL: http://svnweb.freebsd.org/changeset/base/268641 Log: Fix an issue with service(8) where utilities such as screen(1) and tmux(1) would behave differently when utilizing rc-script was invoked manually vs. service(8). The issue being that these utilities require the TERM environ variable to be set and service(8) was not passing it down. Reported by:Michael Dexter edi...@callfortesting.org PR: bin/191869 Reviewed by:allanjude MFC after: 3 days X-MFC-to: stable/10, stable/9 Modified: head/usr.sbin/service/service.sh Modified: head/usr.sbin/service/service.sh == --- head/usr.sbin/service/service.sh Tue Jul 15 01:03:29 2014 (r268640) +++ head/usr.sbin/service/service.sh Tue Jul 15 02:18:55 2014 (r268641) @@ -139,7 +139,7 @@ cd / for dir in /etc/rc.d $local_startup; do if [ -x $dir/$script ]; then [ -n $VERBOSE ] echo $script is located in $dir - exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin $dir/$script $* + exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin TERM=$TERM $dir/$script $* fi done Hm, I'm not sure about this. The behaves differently is exactly the reason for service(8). It runs with a clean environment such as the boot does. Running an rc script without service(8) will give wrong behavior in many scripts that do not match boot-time behavior. Indeed, the whole point is to NOT inherit anything from calling process. If that were the point, then we have an issue. Because as it stands, service(8) does _not_ accurately provide the same environment as boot. Take the following boot script: dte...@scribe9.vicor.com ~ $ cat /etc/rc.d/foo #!/bin/sh # PROVIDE: foo set /tmp/termtest . /etc/rc.subr name=foo rcvar=foo_enable command=/usr/local/bin/tmux foo_flags=new -s foo ls load_rc_config $name run_rc_command $1 Now reboot to find the following in /tmp/termtest: dte...@scribe9.vicor.com ~ $ cat /tmp/termtest HOME=/ ID=/usr/bin/id IDCMD='if [ -x /usr/bin/id ]; then /usr/bin/id -un; fi' IFS=' ' JID=0 OPTIND=1 PATH=/sbin:/bin:/usr/sbin:/usr/bin PPID=1 PS1='# ' PS2=' ' PS4='+ ' PS='/bin/ps -ww' PWD=/ RC_PID=19 SYSCTL=/sbin/sysctl SYSCTL_N='/sbin/sysctl -n' SYSCTL_W=/sbin/sysctl _arg=faststart _boot=faststart _file=/etc/rc.d/foo _rc_conf_loaded=true _rc_elem=/etc/rc.d/foo _rc_elem_done=' /etc/rc.d/sysctl /etc/rc.d/hostid /etc/rc.d/zvol /etc/rc.d/dumpon /etc/rc.d/ddb /etc/rc.d/initrandom /etc/rc.d/geli /etc/rc.d/gbde /etc/rc.d/encswap /etc/rc.d/ccd /etc/rc.d/swap1 /etc/rc.d/fsck /etc/rc.d/root /etc/rc.d/mdconfig /etc/rc.d/hostid_save /etc/rc.d/mountcritlocal /etc/rc.d/zfs /etc/rc.d/var /etc/rc.d/cleanvar /etc/rc.d/FILESYSTEMS ' _rc_namevarlist='program chroot chdir flags fib nice user group groups' _rc_subr_loaded=: accept_sourceroute=NO accounting_enable=NO allscreens_flags='' allscreens_kbdflags='' always_force_depends=NO amd_enable=NO amd_flags='-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map' amd_map_program=NO amd_program=/usr/sbin/amd apm_enable=NO apmd_enable=NO apmd_flags='' arpproxy_all=NO atm_arps='' atm_enable=NO atm_pvcs='' auditd_enable=NO auditd_flags='' auditd_program=/usr/sbin/auditd auditdistd_enable=NO auditdistd_flags='' auditdistd_program=/usr/sbin/auditdistd autoboot=yes background_dhclient=NO background_fsck=YES background_fsck_delay=60 bhyve_enable=NO bhyve_profiles='virt1 virt2' blanktime=300 bootparamd_enable=NO bootparamd_flags='' bsdextended_script=/etc/rc.bsdextended bsnmpd_enable=NO bsnmpd_flags='' bthidd_config=/etc/bluetooth/bthidd.conf bthidd_enable=NO bthidd_hids=/var/db/bthidd.hids check_quotas=YES chkprintcap_enable=NO chkprintcap_flags=-d cleanvar_enable=YES clear_tmp_X=YES clear_tmp_enable=NO cloned_interfaces='' crashinfo_enable=YES crashinfo_program=/usr/sbin/crashinfo cron_dst=YES cron_enable=YES cron_flags='' cron_program=/usr/sbin/cron cursor=NO ddb_config=/etc/ddb.conf ddb_enable=NO defaultroute_carrier_delay=5 defaultroute_delay=30 defaultrouter=172.16.169.2 devd_enable=YES devd_flags='' devfs_load_rulesets=NO devfs_rulesets='/etc/defaults/devfs.rules /etc/devfs.rules' devfs_set_rulesets='' devfs_system_ruleset='' dhclient_flags='' dhclient_program=/sbin/dhclient dir=/usr/local/etc/rc.d dlv=0 dmesg_enable
Re: svn commit: r268641 - head/usr.sbin/service
On 7/15/14, 9:48 PM, dte...@freebsd.org wrote: -Original Message- From: owner-src-committ...@freebsd.org [mailto:owner-src- committ...@freebsd.org] On Behalf Of Mateusz Guzik Sent: Tuesday, July 15, 2014 12:16 PM To: Bryan Drewery Cc: Devin Teske; src-committ...@freebsd.org; svn-src-all@freebsd.org; svn- src-h...@freebsd.org Subject: Re: svn commit: r268641 - head/usr.sbin/service On Tue, Jul 15, 2014 at 12:59:05PM -0500, Bryan Drewery wrote: On 7/14/2014 9:18 PM, Devin Teske wrote: Author: dteske Date: Tue Jul 15 02:18:55 2014 New Revision: 268641 URL: http://svnweb.freebsd.org/changeset/base/268641 Log: Fix an issue with service(8) where utilities such as screen(1) and tmux(1) would behave differently when utilizing rc-script was invoked manually vs. service(8). The issue being that these utilities require the TERM environ variable to be set and service(8) was not passing it down. Reported by: Michael Dexter edi...@callfortesting.org PR: bin/191869 Reviewed by: allanjude MFC after: 3 days X-MFC-to:stable/10, stable/9 Modified: head/usr.sbin/service/service.sh Modified: head/usr.sbin/service/service.sh == --- head/usr.sbin/service/service.shTue Jul 15 01:03:29 2014 (r268640) +++ head/usr.sbin/service/service.shTue Jul 15 02:18:55 2014 (r268641) @@ -139,7 +139,7 @@ cd / for dir in /etc/rc.d $local_startup; do if [ -x $dir/$script ]; then [ -n $VERBOSE ] echo $script is located in $dir - exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin $dir/$script $* + exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin TERM=$TERM $dir/$script $* fi done Hm, I'm not sure about this. The behaves differently is exactly the reason for service(8). It runs with a clean environment such as the boot does. Running an rc script without service(8) will give wrong behavior in many scripts that do not match boot-time behavior. Indeed, the whole point is to NOT inherit anything from calling process. If that were the point, then we have an issue. Because as it stands, service(8) does _not_ accurately provide the same environment as boot. Take the following boot script: dte...@scribe9.vicor.com ~ $ cat /etc/rc.d/foo #!/bin/sh # PROVIDE: foo set /tmp/termtest . /etc/rc.subr name=foo rcvar=foo_enable command=/usr/local/bin/tmux foo_flags=new -s foo ls load_rc_config $name run_rc_command $1 Now reboot to find the following in /tmp/termtest: dte...@scribe9.vicor.com ~ $ cat /tmp/termtest HOME=/ ID=/usr/bin/id IDCMD='if [ -x /usr/bin/id ]; then /usr/bin/id -un; fi' IFS=' ' JID=0 OPTIND=1 PATH=/sbin:/bin:/usr/sbin:/usr/bin PPID=1 PS1='# ' PS2=' ' PS4='+ ' PS='/bin/ps -ww' PWD=/ RC_PID=19 SYSCTL=/sbin/sysctl SYSCTL_N='/sbin/sysctl -n' SYSCTL_W=/sbin/sysctl _arg=faststart _boot=faststart _file=/etc/rc.d/foo _rc_conf_loaded=true _rc_elem=/etc/rc.d/foo _rc_elem_done=' /etc/rc.d/sysctl /etc/rc.d/hostid /etc/rc.d/zvol /etc/rc.d/dumpon /etc/rc.d/ddb /etc/rc.d/initrandom /etc/rc.d/geli /etc/rc.d/gbde /etc/rc.d/encswap /etc/rc.d/ccd /etc/rc.d/swap1 /etc/rc.d/fsck /etc/rc.d/root /etc/rc.d/mdconfig /etc/rc.d/hostid_save /etc/rc.d/mountcritlocal /etc/rc.d/zfs /etc/rc.d/var /etc/rc.d/cleanvar /etc/rc.d/FILESYSTEMS ' _rc_namevarlist='program chroot chdir flags fib nice user group groups' _rc_subr_loaded=: accept_sourceroute=NO accounting_enable=NO allscreens_flags='' allscreens_kbdflags='' always_force_depends=NO amd_enable=NO amd_flags='-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map' amd_map_program=NO amd_program=/usr/sbin/amd apm_enable=NO apmd_enable=NO apmd_flags='' arpproxy_all=NO atm_arps='' atm_enable=NO atm_pvcs='' auditd_enable=NO auditd_flags='' auditd_program=/usr/sbin/auditd auditdistd_enable=NO auditdistd_flags='' auditdistd_program=/usr/sbin/auditdistd autoboot=yes background_dhclient=NO background_fsck=YES background_fsck_delay=60 bhyve_enable=NO bhyve_profiles='virt1 virt2' blanktime=300 bootparamd_enable=NO bootparamd_flags='' bsdextended_script=/etc/rc.bsdextended bsnmpd_enable=NO bsnmpd_flags='' bthidd_config=/etc/bluetooth/bthidd.conf bthidd_enable=NO bthidd_hids=/var/db/bthidd.hids check_quotas=YES chkprintcap_enable=NO chkprintcap_flags=-d cleanvar_enable=YES clear_tmp_X=YES clear_tmp_enable=NO cloned_interfaces='' crashinfo_enable=YES crashinfo_program=/usr/sbin/crashinfo cron_dst=YES cron_enable=YES cron_flags='' cron_program=/usr/sbin/cron cursor=NO ddb_config=/etc/ddb.conf ddb_enable=NO defaultroute_carrier_delay=5 defaultroute_delay=30 defaultrouter=172.16.169.2 devd_enable=YES devd_flags='' devfs_load_rulesets=NO devfs_rulesets='/etc/defaults/devfs.rules /etc/devfs.rules' devfs_set_rulesets='' devfs_system_ruleset='' dhclient_flags='' dhclient_program=/sbin/dhclient dir=/usr/local/etc/rc.d dlv=0 dmesg_enable=YES dummynet_enable=NO dumpdev=NO dumpdir
Re: svn commit: r268641 - head/usr.sbin/service
On Jul 15, 2014, at 7:13 PM, dte...@freebsd.org wrote: I would argue that not all programs are going to like having a nearly empty environment. Things like TERM and SHLVL at the very least should be passed (after-all, the boot process takes place on [a] a terminal and [b] in a shell). Having launchd scrub every processes environment down to nothing, then have environment variables be set explicitly as part of that processes’ “launch contract” was one of the best decisions we ever made at Apple. The Unix process environment is a septic tank, and that’s actually being kind since most septic tanks don’t also contain bottles of nerve gas and the occasional live hand grenade. Many parts of the environment are trivially attackable, and if anyone on the CC line thinks they know the full extent of that attack surface, they’re wrong. Not because there aren’t some extremely smart Unix people in the audience, but because it’s simply impossible to know how each and every environment variable will be used, how it can overflow, or how it can be used to permute a program’s behavior in unpredictable ways. Even if the intention isn’t to be hostile, you can still cause some truly Heisenbergian results by having the environment be unpredictable in nature. It may not be “Unixy”, but Unix didn’t grow up in a world with millions of instances of itself or the big, bad Internet encompassing pretty much every country on earth. Changes need to be made to keep up with the times, and you can rest assured that FreeBSD’s competition is making those changes or has already made them. I also find it a frankly weird assertion that a background service would care about the value of TERM. That sounds like a pretty warped service to me, since assuming interactivity is more the exception than the rule these days. - Jordan ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r268641 - head/usr.sbin/service
On Jul 15, 2014, at 7:40 PM, dte...@freebsd.org wrote: I define non-UNIXy as chicanery that makes working in a POSIX environment more difficult POSIX does not define or mandate any specific set of environment variables. OS X is POSIX and UNIX03 compliant (and qualified to use the Unix trademark, unlike FreeBSD), and I’ve already described its behavior with respect to environment variables. Be careful how you sling terms like POSIX or Unix™ around. ;-) - Jordan ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
RE: svn commit: r268641 - head/usr.sbin/service
-Original Message- From: owner-src-committ...@freebsd.org [mailto:owner-src- committ...@freebsd.org] On Behalf Of Bryan Drewery Sent: Tuesday, July 15, 2014 10:59 AM To: Devin Teske; src-committ...@freebsd.org; svn-src-all@freebsd.org; svn- src-h...@freebsd.org Subject: Re: svn commit: r268641 - head/usr.sbin/service [snip] Running an rc script without service(8) will give wrong behavior in many scripts that do not match boot-time behavior. As far as I can tell, TERM is not set on boot. So the rc script would also not work on boot. So this change is wrong. So we're saying that service should only be used for boot-scripts when in reality not all rc.d scripts may be used at boot but some may be used as service scripts invoked only at multi-user runtime? -- Devin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r268641 - head/usr.sbin/service
On Tue, Jul 15, 2014 at 07:13:44PM -0700, dte...@freebsd.org wrote: destroying all vestiges of that environment purely for the sake of saying it's clean seems counter to the UNIX pathos. I think you mean ethos here, but frankly I like it better this way. mcl ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r268641 - head/usr.sbin/service
On 15 July 2014 22:08, Mark Linimon lini...@lonesome.com wrote: On Tue, Jul 15, 2014 at 07:13:44PM -0700, dte...@freebsd.org wrote: destroying all vestiges of that environment purely for the sake of saying it's clean seems counter to the UNIX pathos. I think you mean ethos here, but frankly I like it better this way. I'm a bit confused by this thread. screen and tmux are interactive processes. They're not designed to be run as UNIX services. Why is this even happening? -a ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
RE: svn commit: r268641 - head/usr.sbin/service
-Original Message- From: Bryan Drewery [mailto:bdrew...@freebsd.org] Sent: Tuesday, July 15, 2014 8:44 PM To: dte...@freebsd.org; 'Mateusz Guzik' Cc: src-committ...@freebsd.org; svn-src-all@freebsd.org; svn-src- h...@freebsd.org Subject: Re: svn commit: r268641 - head/usr.sbin/service On 7/15/14, 9:48 PM, dte...@freebsd.org wrote: -Original Message- From: owner-src-committ...@freebsd.org [mailto:owner-src- committ...@freebsd.org] On Behalf Of Mateusz Guzik Sent: Tuesday, July 15, 2014 12:16 PM To: Bryan Drewery Cc: Devin Teske; src-committ...@freebsd.org; svn-src-all@freebsd.org; svn- src-h...@freebsd.org Subject: Re: svn commit: r268641 - head/usr.sbin/service On Tue, Jul 15, 2014 at 12:59:05PM -0500, Bryan Drewery wrote: On 7/14/2014 9:18 PM, Devin Teske wrote: Author: dteske Date: Tue Jul 15 02:18:55 2014 New Revision: 268641 URL: http://svnweb.freebsd.org/changeset/base/268641 Log: Fix an issue with service(8) where utilities such as screen(1) and tmux(1) would behave differently when utilizing rc-script was invoked manually vs. service(8). The issue being that these utilities require the TERM environ variable to be set and service(8) was not passing it down. Reported by: Michael Dexter edi...@callfortesting.org PR: bin/191869 Reviewed by: allanjude MFC after:3 days X-MFC-to: stable/10, stable/9 Modified: head/usr.sbin/service/service.sh Modified: head/usr.sbin/service/service.sh == --- head/usr.sbin/service/service.sh Tue Jul 15 01:03:29 2014 (r268640) +++ head/usr.sbin/service/service.sh Tue Jul 15 02:18:55 2014 (r268641) @@ -139,7 +139,7 @@ cd / for dir in /etc/rc.d $local_startup; do if [ -x $dir/$script ]; then [ -n $VERBOSE ] echo $script is located in $dir -exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin $dir/$script $* +exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin TERM=$TERM $dir/$script $* fi done Hm, I'm not sure about this. The behaves differently is exactly the reason for service(8). It runs with a clean environment such as the boot does. Running an rc script without service(8) will give wrong behavior in many scripts that do not match boot-time behavior. Indeed, the whole point is to NOT inherit anything from calling process. If that were the point, then we have an issue. Because as it stands, service(8) does _not_ accurately provide the same environment as boot. Take the following boot script: dte...@scribe9.vicor.com ~ $ cat /etc/rc.d/foo #!/bin/sh # PROVIDE: foo set /tmp/termtest . /etc/rc.subr name=foo rcvar=foo_enable command=/usr/local/bin/tmux foo_flags=new -s foo ls load_rc_config $name run_rc_command $1 Now reboot to find the following in /tmp/termtest: dte...@scribe9.vicor.com ~ $ cat /tmp/termtest HOME=/ ID=/usr/bin/id IDCMD='if [ -x /usr/bin/id ]; then /usr/bin/id -un; fi' IFS=' ' JID=0 OPTIND=1 PATH=/sbin:/bin:/usr/sbin:/usr/bin PPID=1 PS1='# ' PS2=' ' PS4='+ ' PS='/bin/ps -ww' PWD=/ RC_PID=19 SYSCTL=/sbin/sysctl SYSCTL_N='/sbin/sysctl -n' SYSCTL_W=/sbin/sysctl _arg=faststart _boot=faststart _file=/etc/rc.d/foo _rc_conf_loaded=true _rc_elem=/etc/rc.d/foo [snip] Compare that with the following: dte...@scribe9.vicor.com ~ $ sr service foo start dte...@scribe9.vicor.com ~ $ cat /tmp/termtest HOME=/ IFS=' ' OPTIND=1 PATH=/sbin:/bin:/usr/sbin:/usr/bin PPID=1285 PS1='# ' PS2=' ' PS4='+ ' PWD=/ Looks to me like some things are being inherited. Notably, it would appear that the rc.d scripts are run within the parent namespace which has had source_rc_confs() called (I'm leaving alone for the moment that this indicates that each rc-script is being less than efficient by re-sourcing rc.subr). Given the above (that we are farther from a clean environment than one might expect), is it really that big of a deal to expose $TERM? If so, what are the serious issues that could arise? I personally cannot think of any shortcomings or fallout from adding $TERM to be exposed. You said the shortcoming yourself - it doesn't fix the issue at boot. Huh? The proposal is to keep the patch to service(8) and add yet another patch to make $TERM accessible during boot. Right now, with the patch to service(8) as it stands, of the three scenarios where $TERM is accessible to rc.d scripts, only one remains: 1. In multi-user mode when executed directly 2. In multi-user mode when executed via service(8) 3. At boot-time (which does not use service(8)) My patch addressed #2 above, #1 already expands $TERM in an rc.d script, and the proposal is to make a patch for #3 to expand
RE: svn commit: r268641 - head/usr.sbin/service
-Original Message- From: Jordan Hubbard [mailto:jordanhubb...@me.com] Sent: Tuesday, July 15, 2014 9:39 PM To: dte...@freebsd.org Cc: Mateusz Guzik; Bryan Drewery; src-committ...@freebsd.org; svn-src- a...@freebsd.org; svn-src-h...@freebsd.org Subject: Re: svn commit: r268641 - head/usr.sbin/service On Jul 15, 2014, at 7:13 PM, dte...@freebsd.org wrote: I would argue that not all programs are going to like having a nearly empty environment. Things like TERM and SHLVL at the very least should be passed (after-all, the boot process takes place on [a] a terminal and [b] in a shell). Having launchd scrub every processes environment down to nothing, then have environment variables be set explicitly as part of that processes' launch contract was one of the best decisions we ever made at Apple. The Unix process environment is a septic tank, and that's actually being kind since most septic tanks don't also contain bottles of nerve gas and the occasional live hand grenade. Many parts of the environment are trivially attackable, and if anyone on the CC line thinks they know the full extent of that attack surface, they're wrong. Not because there aren't some extremely smart Unix people in the audience, but because it's simply impossible to know how each and every environment variable will be used, how it can overflow, or how it can be used to permute a program's behavior in unpredictable ways. Even if the intention isn't to be hostile, you can still cause some truly Heisenbergian results by having the environment be unpredictable in nature. It may not be Unixy, but Unix didn't grow up in a world with millions of instances of itself or the big, bad Internet encompassing pretty much every country on earth. Changes need to be made to keep up with the times, and you can rest assured that FreeBSD's competition is making those changes or has already made them. I also find it a frankly weird assertion that a background service would care about the value of TERM. That sounds like a pretty warped service to me, since assuming interactivity is more the exception than the rule these days. Odd indeed. An rc.d script needs to know $TERM so it can launch a background instance of screen or tmux. The rc.d script itself doesn't use $TERM but the instance of screen or tmux needs it else it thinks you're not on a terminal (maybe the proper thing is to patch screen and tmux ;D). -- Devin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
RE: svn commit: r268641 - head/usr.sbin/service
From: Jordan Hubbard [mailto:jordanhubb...@me.com] Sent: Tuesday, July 15, 2014 9:42 PM To: dte...@freebsd.org Cc: Benjamin Kaduk; Bryan Drewery; svn-src-h...@freebsd.org; svn-src-all@freebsd.org; src-committ...@freebsd.org Subject: Re: svn commit: r268641 - head/usr.sbin/service On Jul 15, 2014, at 7:40 PM, dte...@freebsd.org mailto:dte...@freebsd.org wrote: I define non-UNIXy as chicanery that makes working in a POSIX environment more difficult POSIX does not define or mandate any specific set of environment variables. OS X is POSIX and UNIX03 compliant (and qualified to use the Unix trademark, unlike FreeBSD), and I've already described its behavior with respect to environment variables. Be careful how you sling terms like POSIX or UnixT around. ;-) [Devin Teske] (smiles) Will do. However I'm re-reading my statement and holding to the meaning I've interred it: Windows has POSIX compliance Mac OS X has POSIX compliance So does Linux, as does FreeBSD If working in one of these POSIX environments (note: the Windows POSIX environment I use is MinGW) compiling C code, using standard POSIX APIs, etc. I view the overall environment as being non-UNIXy if that POSIX environment is not properly integrated. Now, my statement's standpoint is that if my POSIX system has the API calls to inter the terminal type I'm being run within, is the overall system outside ignoring this POSIX-made-available information? So example would be Windows as being non-UNIXy (this I believe we agree upon). Non-UNIXy because while I can load the MinGW or SFU or Cygwin layers to access POSIX-compliant APIs, Windows itself could care less about that layer. It's not integrated. Skipping Mac OS X, looking at FreeBSD, my statement was designed to encapsulate that we actively seek to maintain great compliance with POSIX and also (maybe this is the leap; but I would think) try to make sure we integrate that information as often as possible. (and thus, not force someone to build a layer on-top of the boot process to re-access the data that should perhaps already be made available -- e.g., $TERM to know what we're running within). -- Devin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
RE: svn commit: r268641 - head/usr.sbin/service
-Original Message- From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On Behalf Of Adrian Chadd Sent: Tuesday, July 15, 2014 10:19 PM To: Mark Linimon Cc: Devin Teske; Mateusz Guzik; Bryan Drewery; svn-src-h...@freebsd.org; svn-src-all@freebsd.org; src-committ...@freebsd.org Subject: Re: svn commit: r268641 - head/usr.sbin/service On 15 July 2014 22:08, Mark Linimon lini...@lonesome.com wrote: On Tue, Jul 15, 2014 at 07:13:44PM -0700, dte...@freebsd.org wrote: destroying all vestiges of that environment purely for the sake of saying it's clean seems counter to the UNIX pathos. I think you mean ethos here, but frankly I like it better this way. I'm a bit confused by this thread. screen and tmux are interactive processes. They're not designed to be run as UNIX services. Why is this even happening? You can instantiate a pre-detached named-session. -- Devin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r268641 - head/usr.sbin/service
Author: dteske Date: Tue Jul 15 02:18:55 2014 New Revision: 268641 URL: http://svnweb.freebsd.org/changeset/base/268641 Log: Fix an issue with service(8) where utilities such as screen(1) and tmux(1) would behave differently when utilizing rc-script was invoked manually vs. service(8). The issue being that these utilities require the TERM environ variable to be set and service(8) was not passing it down. Reported by: Michael Dexter edi...@callfortesting.org PR: bin/191869 Reviewed by: allanjude MFC after:3 days X-MFC-to: stable/10, stable/9 Modified: head/usr.sbin/service/service.sh Modified: head/usr.sbin/service/service.sh == --- head/usr.sbin/service/service.shTue Jul 15 01:03:29 2014 (r268640) +++ head/usr.sbin/service/service.shTue Jul 15 02:18:55 2014 (r268641) @@ -139,7 +139,7 @@ cd / for dir in /etc/rc.d $local_startup; do if [ -x $dir/$script ]; then [ -n $VERBOSE ] echo $script is located in $dir - exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin $dir/$script $* + exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin TERM=$TERM $dir/$script $* fi done ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
