bin/90518: dhclient-script problems with symlink'd resolv.conf when /etc is read-only

John E. Hein jhein at timing.com
Fri Dec 16 12:50:10 PST 2005


>Number:         90518
>Category:       bin
>Synopsis:       dhclient-script problems with symlink'd resolv.conf when /etc is read-only
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Dec 16 20:50:03 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     John E. Hein
>Release:        FreeBSD 4.8-RELEASE i386
>Organization:
Timing Solutions
>Environment:
System: noticed on 4.x; still appears to be a problem on -current


>Description:
	Some situations - embedded products, for instance - call
	for a read-only root (& /etc) file system.  In such cases,
	we sym-link /etc/resolv.conf to a writable file system
    (e.g., /some/where/etc/resolv.conf).

    In 4.x, the 'rm /etc/resolv.conf.std' in dhclient-script fails
    and lines are appended to the actual resolv.conf file.  Over
    time, it can get quite large (in the case where new_domain_name
    is empty and thus the rm /etc/resolv.conf is attempted)).  In
    this case the easy fix is 'cp /dev/null /etc/resolv.conf' rather
    than using 'rm'.

    In -current, the problem is similar but the effect can be
    different.  The way dhclient-script works there, a temporary
    /etc/resolv.conf.std file is written to, then its contents is
    cat'd to the real resolv.conf.

    If /etc/resolv.conf.std does not exist on a read-only /etc,
    resolv.conf will never populate.

    If /etc/resolv.conf.std is a sym link (because the someone using
    a read-only /etc has looked into dhclient-script and seen what
    files it writes to), then you will hit the 'growing' resolv.conf
    issue described above.

    NB: I have not actually tried it on -current yet.  I have just
    looked at the add_new_resolv_conf() function.  If I did not dig
    deep enough, I apologize.  I'll try to verify it on -current
    when I get a chance.

>How-To-Repeat:
	mount -ur /

	Then run dhclient for your interface (using a dhcp server that
    supplies DNS server info).

    Observe the effects (or lack thereof) on resolv.conf

>Fix:

	Here's a patch for -current.  The choice of using TMPDIR
	may be wrong.  There could be a possible security issue,
	but I'm not clear about all the ways dhclient-script can
	be invoked.  Writing to a less accessible directory might
	be prudent.  And using an env var here may allow a malicious
	user could point TMPDIR somewhere undesirable.

    Somewhere under /var/run might be a better place.

    OpenBSD's version has the same problem.

Index: dhclient-script
===================================================================
RCS file: /base/FreeBSD-CVS/src/sbin/dhclient/dhclient-script,v
retrieving revision 1.10
diff -u -p -r1.10 dhclient-script
--- dhclient-script	8 Sep 2005 22:49:17 -0000	1.10
+++ dhclient-script	16 Dec 2005 20:31:52 -0000
@@ -134,21 +134,22 @@ add_new_resolv_conf() {
 	# thus broke the script. This code creates the resolv.conf if either
 	# are provided.
 
-	rm -f /etc/resolv.conf.std
+	local tmpres=${TMPDIR:-/tmp}/resolv.conf.std
+	rm -f $tmpres
 
 	if [ -n "$new_domain_name" ]; then
-		echo "search $new_domain_name" >>/etc/resolv.conf.std
+		echo "search $new_domain_name" >>$tmpres
 	fi
 
 	if [ -n "$new_domain_name_servers" ]; then
 		for nameserver in $new_domain_name_servers; do
-			echo "nameserver $nameserver" >>/etc/resolv.conf.std
+			echo "nameserver $nameserver" >>$tmpres
 		done
 	fi
 
-	if [ -f /etc/resolv.conf.std ]; then
+	if [ -f $tmpres ]; then
 		if [ -f /etc/resolv.conf.tail ]; then
-			cat /etc/resolv.conf.tail >>/etc/resolv.conf.std
+			cat /etc/resolv.conf.tail >>$tmpres
 		fi
 
 		# When resolv.conf is not changed actually, we don't
@@ -156,8 +157,8 @@ add_new_resolv_conf() {
 		# If /usr is not mounted yet, we cannot use cmp, then
 		# the following test fails.  In such case, we simply
 		# ignore an error and do update resolv.conf.
-		if cmp -s /etc/resolv.conf.std /etc/resolv.conf; then
-			rm -f /etc/resolv.conf.std
+		if cmp -s $tmpres /etc/resolv.conf; then
+			rm -f $tmpres
 			return 0
 		fi 2>/dev/null
 
@@ -168,8 +169,8 @@ add_new_resolv_conf() {
 		if [ -f /etc/resolv.conf ]; then
 			cat /etc/resolv.conf > /etc/resolv.conf.save
 		fi
-		cat /etc/resolv.conf.std > /etc/resolv.conf
-		rm -f /etc/resolv.conf.std
+		cat $tmpres > /etc/resolv.conf
+		rm -f $tmpres
 
 		# Try to ensure correct ownership and permissions.
 		chown -RL root:wheel /etc/resolv.conf
>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list