From wes@bogon.net  Fri Mar 17 20:47:56 2006
Return-Path: <wes@bogon.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id CD09B16A401
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 17 Mar 2006 20:47:56 +0000 (UTC)
	(envelope-from wes@bogon.net)
Received: from bogon.dnsalias.net (168-103-224-74.ptld.qwest.net [168.103.224.74])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 38D0343D7B
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 17 Mar 2006 20:47:52 +0000 (GMT)
	(envelope-from wes@bogon.net)
Received: from [10.0.0.3] (starbug.wifi.bogon.net [10.0.0.3])
	by mail-jail.wifi.bogon.net (Postfix) with ESMTP id 679C711423
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 17 Mar 2006 12:47:50 -0800 (PST)
Message-Id: <441B2071.1000800@bogon.net>
Date: Fri, 17 Mar 2006 12:47:45 -0800
From: Wes Santee <wes@bogon.net>
To: FreeBSD-gnats-submit@freebsd.org
Subject: security/tor-devel defaults data directory to non-persistent storage
 location

>Number:         94621
>Category:       ports
>Synopsis:       security/tor-devel defaults data directory to non-persistent storage location
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-ports-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Mar 17 20:50:14 GMT 2006
>Closed-Date:    Thu Mar 23 02:09:46 GMT 2006
>Last-Modified:  Thu Mar 23 02:09:46 GMT 2006
>Originator:     Wes Santee
>Release:        FreeBSD 6.0-STABLE i386
>Organization:
N/A
>Environment:
System: FreeBSD lister.wifi.bogon.net 6.0-STABLE FreeBSD 6.0-STABLE #3:
Tue Feb 21 15:35:34 PST 2006
root@lister.internal.bogon.net:/storage/usr/obj/usr/src/sys/LISTER i386


>Description:
	The security/tor-devel port installs /usr/local/etc/rc.d/tor.sh.
	This script handles the starting and stopping of the tor process
	when tor_enabled="YES" is in /etc/rc.conf.

	The script overrides the value of DataDirectory in the
	/usr/local/etc/tor/torrc file by defining the variable
	tor_datadir.  The problem is that tor_datadir (in addition
	to not being a documented variable in the comments of the
	script) points to /var/run/tor.

	Since /var/run is emptied during system startup (by way of
	/etc/rc.d/cleanvar), the tor server's secret key is erased
	each time the system is started.  This causes an entirely
	new server fingerprint to be created each time.  This
	fingerprint must stay the same for the server to be recognized
	on the tor network.

>How-To-Repeat:
	1) Install /security/tor-devel with default options
	2) Configure as a server in /usr/local/etc/tor/torrc
	   (specify ORPort and DirPort).
	3) Add "tor_enable=YES" to /etc/rc.conf and start tor
	   via /usr/local/etc/rc.d/tor.sh start.
	4) Check fingerprint in /var/run/tor/fingerprint
	5) Reboot system
	6) When system comes up again, check fingerprint file.
           It will probably have changed as a result of the
	   keyfile being deleted and regenerated.

>Fix:

	1) Do not use a default of /var/run/tor for the data directory.
	2) If the tor.sh startup script is going to override what
	   is in the torrc, document the variable in the script file.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: edwin 
State-Changed-When: Fri Mar 17 20:52:09 UTC 2006 
State-Changed-Why:  
Awaiting maintainers feedback 

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

From: Peter Thoenen <eol1@yahoo.com>
To: bug-followup@FreeBSD.org
Cc: wes@bogon.net
Subject: Re: ports/94621: security/tor-devel defaults data directory to non-persistent
Date: Sun, 19 Mar 2006 05:15:36 -0800 (PST)

 Give me a day or three to think about this one.  Will include a fix in
 1.1.16-blah whenever that comes out.  Not a fan of the suggested #1
 solution as it would appear to break hier(7) nor am I a fan of #2
 though its certainly double and a GOOD IDEA (tm).  Going to discuss
 some things with the tor developers (e.g. is there an undocumented
 option that allows one to point directly to a keyfile outside the
 DataDir) before I fix this.  Good catch Wes as I only use tor in client
 mode.  Let me know if you catch any other server specific items that
 are broken.
 
 OT Rant: How is it I never get these emails.  Has to be the 4th or 5th
 PR I have detected via a search query that affect ports I maintain. 
 Its how I found this PR for example.

From: Peter Thoenen <eol1@yahoo.com>
To: bug-followup@FreeBSD.org
Cc: wes@bogon.net
Subject: Re: ports/94621: security/tor-devel defaults data directory to non-persistent
Date: Wed, 22 Mar 2006 13:02:18 -0800 (PST)

 Well 1.1.16-blah came way faster than I expected but here is what I did
 after a rather lengthy (and disagreable) talk with the tor developers.
 
 1) Documented tor_datadir in the rc.subr file as suggested by Wes.
 2) Moved tor from /var/run to /var/db*
 
 * I really really don't like this solution though Arma beat it into my
 head the current solution is wrong also.  The prob is, unlike lets say
 squid or postgres, they do not split their cache directory (nor any
 directive to do so) from their static content directory.  This presents
 a problem in my eyes with hier(7).
 
 I don't like %%LOCALBASE%%/share as this should NOT be for temporary
 volatile files (e.g. tor's cache files).  var/run is wrong as it is
 cleared on reboot and not only is the fingerprint file needed (and no
 way to move it) its best also not to wipe your server descriptors
 though not show stopper (just longer initial startup time).  var/tmp is
 proper but I believe a lot of people "ln -s /tmp /var/tmp" and
 clear_tmp_enable would then cause the same prob as var/run in this
 case.  I don't believe var/db is the correct place for this either but
 gets around the var/run and var/tmp issues while in theory satisfying
 hier(7).  Another problem though is placing it ANYWHERE in var is
 problematic as some folk out there are really excited about putting
 /var on MFS and rebuilding after each reboot for some odd reason
 clearning everything as far as I can tell.
 
 The new solution works and should address this PR .. I just personally
 don't like it.  I also don't have a better solution so would prefer to
 make it work (tm) than leave it broke while stonewalling over basically
 terminology and an intelligentsia problem.  Thanks again Wes for
 pointing this out.
 
 NOTE See: http://www.freebsd.org/cgi/query-pr.cgi?pr=93692
State-Changed-From-To: feedback->closed 
State-Changed-By: linimon 
State-Changed-When: Thu Mar 23 02:09:19 UTC 2006 
State-Changed-Why:  
See ports/93692. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=94621 
>Unformatted:
