Date: Wed, 22 Mar 2006 21:10:21 GMT From: Peter Thoenen <eol1@yahoo.com> To: freebsd-ports-bugs@FreeBSD.org Subject: Re: ports/94621: security/tor-devel defaults data directory to non-persistent Message-ID: <200603222110.k2MLALkV033842@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR ports/94621; it has been noted by GNATS. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603222110.k2MLALkV033842>