ports/94621: security/tor-devel defaults data directory to non-persistent

[Peter Thoenen]

The following reply was made to PR ports/94621; it has been noted by GNATS.

From: Peter Thoenen <eol1 at yahoo.com>
To: bug-followup at FreeBSD.org
Cc: wes at 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