[tor-bugs] #7956 [Tor]: Tor uses Roaming (remote) AppData, not Local

[Tor Bug Tracker & Wiki]

#7956: Tor uses Roaming (remote) AppData, not Local
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:
  cypherpunks            |     Status:  new
         Type:  defect   |  Milestone:  Tor: 0.2.5.x-final
     Priority:  major    |    Version:  Tor: unspecified
    Component:  Tor      |   Keywords:  tor-client win32 024-backport
   Resolution:           |  AppData Roaming Local Windows
Actual Points:           |  Parent ID:
       Points:           |
-------------------------+-------------------------------------------------

Comment (by GITNE):

 Replying to [comment:11 nickm] and [comment:10 nickm]:
 > (to be clear: that migration plan is a draft and it is probably
 improvable)

 This plan makes sense but only theoretically because it won't work in
 practice.

 [[BR]]
 A changeset implementing this ticket ''should'' also implement #10027 (and
 vice versa) because both tickets have equal side effects. They cause Tor
 to regenerate its private key (identity) and caches. Hence, users should
 be spared the double hassle.

 Adding code to Tor migrating its configuration and cache folder from
 {{{%APPDATA%}}} to {{{%LOCALAPPDATA%}}} is rather trivial but migrating it
 from one account to another is not. The problem is that moving a folder
 from one account profile to another requires running under the "{{{NT
 AUTHORITY\SYSTEM}}}" ({{{LocalSystem}}}) pseudo account or an account in
 the {{{Administrators}}} group. Windows Vista and later offer UAC
 (equivalent to {{{sudo}}}) to easily aquire an administrator's account for
 such an — one time — operation so this seems like a viable solution to
 this migration problem. But, it's not. Windows versions prior to Windows
 Vista don't support UAC. Therefor this approach is limited.

 Because by convention Windows applications do not do setup or installation
 tasks they are left to or taken care of by the installer. So the preferred
 way would be to put the migration code into the installer. Installers are
 always executed under an administrator's or the {{{LocalSystem}}} account
 (or with the "{{{NT SERVICE\TrustedInstaller}}}" pseudo account since
 Windows Vista, but this is of no concern here). Hence an installer can
 almost literally do anything to a machine while running; like moving
 folders between profiles and modifying their ownerships and DACLs. This
 way, there is no need to add and maintain migration code in the Tor
 executable. And, Tor is free of the hassle to aquire or impersonate an
 administrator's account.

 The last time I have checked the downloads page of the Tor project, I have
 seen that the Tor standalone bundle is wrapped into an installer too. So
 the above described migration path via the installer should also be
 applicable to the Tor standalone bundle. Only users who compile Tor or
 extract Tor from the install bundles and install it manually would need to
 be aware of this change and handle the migration manually. But, since they
 are installing Tor manually anyway they can be expected and should be able
 to do it on their own.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7956#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online