From nobody@FreeBSD.org  Tue Mar 11 23:05:33 2014
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
	(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hub.freebsd.org (Postfix) with ESMTPS id 9FF68D9E
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 11 Mar 2014 23:05:33 +0000 (UTC)
Received: from cgiserv.freebsd.org (cgiserv.freebsd.org [IPv6:2001:1900:2254:206a::50:4])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx1.freebsd.org (Postfix) with ESMTPS id 8D2B5EB4
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 11 Mar 2014 23:05:33 +0000 (UTC)
Received: from cgiserv.freebsd.org ([127.0.1.6])
	by cgiserv.freebsd.org (8.14.8/8.14.8) with ESMTP id s2BN5XjC050069
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 11 Mar 2014 23:05:33 GMT
	(envelope-from nobody@cgiserv.freebsd.org)
Received: (from nobody@localhost)
	by cgiserv.freebsd.org (8.14.8/8.14.8/Submit) id s2BN5XlE050068;
	Tue, 11 Mar 2014 23:05:33 GMT
	(envelope-from nobody)
Message-Id: <201403112305.s2BN5XlE050068@cgiserv.freebsd.org>
Date: Tue, 11 Mar 2014 23:05:33 GMT
From: Adam McDougall <mcdouga9@egr.msu.edu>
To: freebsd-gnats-submit@FreeBSD.org
Subject: sysrc mishandles variable names containing a dot
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         187461
>Category:       bin
>Synopsis:       sysrc(8) mishandles variable names containing a dot
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    dteske
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Mar 11 23:10:00 UTC 2014
>Closed-Date:    
>Last-Modified:  Wed Apr 16 01:48:22 UTC 2014
>Originator:     Adam McDougall
>Release:        FreeBSD 10.0-STABLE
>Organization:
>Environment:
FreeBSD build10 10.0-STABLE FreeBSD 10.0-STABLE #0 r262298: Fri Feb 21 18:28:26 EST 2014     root@build10:/usr/obj/usr/src/sys/BUILD10  amd64
>Description:
Recently I was trying to convert some "echo a.b.c=1 > /etc/sysctl.conf" type statements to use sysrc instead.  It appears if the variable contains one or more dots, sysrc will write the desired value, fail to read it, and it will always create a new entry if executed again.  This is inconvenient for editing values in /etc/sysctl.conf using the -f parameter because such entries almost always have a dot in the variable.

sysrc -f /etc/sysctl.conf

Symptoms are present on FreeBSD 9 too.
>How-To-Repeat:
root@build10:~ # grep a.b /etc/rc.conf
root@build10:~ # sysrc a.b=yes
a.b:  -> 
root@build10:~ # grep a.b /etc/rc.conf
a.b="yes"
root@build10:~ # sysrc a.b=yes
a.b:  -> 
root@build10:~ # grep a.b /etc/rc.conf
a.b="yes"
a.b="yes"

>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->dteske 
Responsible-Changed-By: eadler 
Responsible-Changed-When: Wed Mar 12 00:36:24 UTC 2014 
Responsible-Changed-Why:  
Over to maintainer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=187461 

From: <dteske@FreeBSD.org>
To: <bug-followup@FreeBSD.org>, <mcdouga9@egr.msu.edu>
Cc: <dteske@FreeBSD.org>
Subject: Re: bin/187461: sysrc mishandles variable names containing a dot
Date: Wed, 19 Mar 2014 15:28:01 -0700

 While I can agree that a tool *like* sysrc is needed for
 editing files like /etc/sysctl.conf (and /boot/loader.conf),
 sysrc is not that tool.
 
 The tool for that job is being developed and is named
 "sysconf". Here is the code which is written in C and is
 almost functional (can read but not yet write out changes):
 
 http://druidbsd.cvs.sf.net/viewvc/druidbsd/sysconf/
 
 The sysconf tool will have a syntax that is nearly identical
 to sysrc. The break-down between functionality that
 requires two separate utilities is as-such:
 
 sysrc is written in shell and uses shell to parse shell (rc-
 files are actually shell).
 
 sysconf is written in C and uses C to parse text while
 keeping to the rules that are used by loader.4th to
 parse loader.conf (which happens to be slightly more
 strict but compatible with how sysctl.conf is parsed).
 
 The tool should fit the job.
 
 While the bigger picture is to wait for sysconf, would you
 be interested in a patch that actively aborts sysrc if you
 attempt to pass a variable that appears invalid?
 
 I'm 50% looking for a POLA violation to say we should
 definitely filter input, and 50% saying we shouldn't stop
 the user from doing something that appears incorrect
 because we could potentially prevent them from doing
 something clever.
 
 As it stands, I fully expect the error that comes from
 asking sh(1) to expand a variable that contains dots.
 -- 
 Devin
 
 _____________
 The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

From: Adam McDougall <mcdouga9@egr.msu.edu>
To: dteske@FreeBSD.org, bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/187461: sysrc mishandles variable names containing a dot
Date: Wed, 19 Mar 2014 22:39:57 -0400

 On 03/19/2014 18:28, dteske@FreeBSD.org wrote:
 > While I can agree that a tool *like* sysrc is needed for
 > editing files like /etc/sysctl.conf (and /boot/loader.conf),
 > sysrc is not that tool.
 
 Fair enough.  I'll admit I've used it to modify /etc/periodic.conf as
 well, but that is probably similar enough.
 
 > 
 > The tool for that job is being developed and is named
 > "sysconf". Here is the code which is written in C and is
 > almost functional (can read but not yet write out changes):
 > 
 > http://druidbsd.cvs.sf.net/viewvc/druidbsd/sysconf/
 > 
 > The sysconf tool will have a syntax that is nearly identical
 > to sysrc. The break-down between functionality that
 > requires two separate utilities is as-such:
 > 
 > sysrc is written in shell and uses shell to parse shell (rc-
 > files are actually shell).
 > 
 > sysconf is written in C and uses C to parse text while
 > keeping to the rules that are used by loader.4th to
 > parse loader.conf (which happens to be slightly more
 > strict but compatible with how sysctl.conf is parsed).
 > 
 > The tool should fit the job.
 
 That sounds like it would probably be faster to execute too.
 
 > 
 > While the bigger picture is to wait for sysconf, would you
 > be interested in a patch that actively aborts sysrc if you
 > attempt to pass a variable that appears invalid?
 > 
 > I'm 50% looking for a POLA violation to say we should
 > definitely filter input, and 50% saying we shouldn't stop
 > the user from doing something that appears incorrect
 > because we could potentially prevent them from doing
 > something clever.
 > 
 > As it stands, I fully expect the error that comes from
 > asking sh(1) to expand a variable that contains dots.
 > 
 
 I feel torn, part of me is satisfied with the explanation of
 "it's meant for shell-compatible variables only" (maybe a
 more explicit mention of that in the manpage would help) but
 part of me is still bothered that it silently makes a
 modification to the specified file while visually indicating
 that it did not.  I was probably further drawn into the allure
 because sysrc(8) states "This utility works similar to sysctl"
 :) sysrc(8) also makes claims of appending only once and
 "taking care not to allow the file to grow unwieldy should sysrc
 be called repeatedly" which is not holding true in this
 circumstance.  Is it possible to withhold the file editing
 until sysrc has executed far enough along that it realizes it
 thinks it is trying to set a null variable and abort?  Thanks
 for your attention.
 
 
 
 
>Unformatted:
