[tor-talk] Firefox Portable and Access Denied on Lock File (Windows, x64) (Was: Tor Browser Bundle 3.0alpha1 test builds)

[Jeffrey Walton <noloader@xxxxxxxxx>]

Hi All/Mike,

My apologies for spinning up another thread. The original seemed like
it was getting cluttered, and I believe the cause has been found.

In this installation, the Tor bundle was installed in %PROGRAMFILES%.
Specifically, C:\Program Files (x86)\Tor Browser.

If I run "Start Tor Browser.exe" as a regular user, I receive an error
message, "Firefox is already running, but not responding...". See
"tor-firefox-windows-already-running.png" at
http://postimg.org/image/cf8ily0sp/.

When I trace the processes involved (Start Tor, Tor, and Firefox)
using Sysinternal's Process Monitor, it appears Firefox is trying to
write a lock file in %PROGRAMFILES%. The lock file is ...\Tor
Browser\FirefoxPortable\Data\Profile\parent.lock, and it results in an
ACCESS_DENIED. See "tor-firefox-windows-access-denied.png" at
http://postimg.org/image/xlzmb3j1b/.

If I run "Start Tor Browser.exe" as an Administrator, the browser works fine.

When the Tor Browser is launched after installation (as part of the
installation), the browser works fine. I believe this is because the
setup/install program is not dropping privileges after it completes.

In this case, FirefoxPortable should probably be writing its lock file
to a temporary directory or the User's application data directory
(CSIDL_APPDATA or FOLDERID_RoamingAppData,
http://msdn.microsoft.com/en-us/library/windows/desktop/dd378457%28v=vs.85%29.aspx).
It should not attempt to write to a read/execute directory.

Jeff

On Fri, Jun 14, 2013 at 10:39 PM, Mike Perry <mikeperry@xxxxxxxxxxxxxx> wrote:
> The new TBB 3.0 series is almost ready for its first alpha release!
>
> Here are the major highlights of the 3.0 series:
>
>  1. Usability, usability, usability! We've attempted to solve several
>     major usability issues in this series, including:
>
>     A. No more Vidalia. The Tor process management is handled by the Tor
>        Launcher extension. If you want the Vidalia features, you can
>        point an existing Vidalia binary at control port 9151 after Tor
>        Browser has launched, and it should still work.
>
>     B. The browser now uses a local about:tor homepage instead of
>        check.torproject.org. A local verification against the control port
>        is still performed, to ensure Tor is working, and a link to
>        check.torproject.org is provided from the about:Tor homepage
>        for manual verification as well.
>
>     C. For Windows users: an NSIS-based extractor now guides you through
>        the TBB extraction and ensures the extracted bundle ends up on your
>        Desktop, or in a known location chosen by you. Hopefully this
>        will mean no more losing track of the extracted bundle files!
>
>  2. The bundles are all under the 25M gmail attachment size limit, so
>     direct email and gettor attachments are once again possible.
>
>  3. We now use Gitian to build the bundles. The idea behind Gitian is to
>     allow independent people to take our source code and produce exactly
>     identical binaries on their own. We're not quite at the point where
>     you always get a matching build, but the remaining differences are
>     minor, and within a couple more releases we should have it fully
>     reproducible. For now, we are posting all of the builds for
>     comparison, and you can of course build and compare your own:
>     https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gitian/README.build
>
>
> Please try these out, test them, and give us feedback! The plan is to
> post them on the blog by Monday, unless something goes horribly wrong.
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk