Default sysdirs on Windows should be changed

[Diogo Pereira]

On Windows, the personal and plus ado directories are, by default, under C:\ado.

On multi-user systems, this default setting is either very inconvenient if users do not have write permissions in C:\ado, since then they cannot use ssc install without first figuring out how to change their PLUS directory; or extremely insecure if they do have such write permissions, since then any user can place a malicious program in another user's ado path. This is quite serious, considering that ado programs allow you to run arbitrary shell commands, and the default Windows permissions on C:\ allow users to create directories there!

These defaults should be changed to be under some directory in %APPDATA% (e.g. %APPDATA%\Stata\ado\plus), since that is the correct place to store per-user application-specific files on Windows.[1]

Until the defaults change, you can fix this in sysprofile.do:

local APPDATA : environment APPDATA
capture mkdir "`APPDATA'\Stata"
sysdir set PLUS "`APPDATA'\Stata\ado\plus"
sysdir set PERSONAL "`APPDATA'\Stata\ado\personal"
sysdir set OLDPLACE "`APPDATA'\Stata\ado"

[wbuchanan]

And what if you only want to have a single location for ado files available for all users? A directory does not inherently posses permissions and having read and execute permissions does not guarantee write permissions to any specific locations. I'm agnostic to changing the path on Windows systems, but I don't think modifying the path will have as much of an effect as you might think (e.g., regardless of the location of the path it is still possible to shell out).

[Diogo Pereira]

And what if you only want to have a single location for ado files available for all users?

That's what SITE is for. By default that is inside Stata's installation directory (in Program Files), so it can only be written to by administrators.

I think I may not have been very clear in my initial post. The problem is that if you have a world-writable directory in your adopath, then anyone can create or change programs there to do malicious things when they are run by other users. For example, I could add this line to C:\ado\plus\e\estout.ado:

shell rmdir /s /q C:\Users\wbuchanan

If I then run estout, that command doesn't do anything because I don't have permissions to remove your files. However, I can just wait until you run estout, and then you will unwittingly delete your own files.

[William Lisowski]

I note that as shown below, Stata for Mac (and presumably for Stata for UNIX) both behave in the requested fashion, with the PLUS and PERSONAL directories within the home directory of the user logged in ("~" in UNIX-speak, below). Also, they restrict writability of each of the directories suitably: STATA and BASE are restricted to writing by root and those granted administrator rights, while PLUS and PERSONAL are writable only by the individual user.

Stata for Windows seems to be the outlier here, but then, I haven't had to use Windows in several years and don't remember what the multi-user capabilities of its filesystem are.

From within Stata:

. about

Stata/SE 14.2 for Mac (64-bit Intel)
Revision 07 Mar 2017
Copyright 1985-2015 StataCorp LLC

  ...

. sysdir
   STATA:  /Applications/Stata/
    BASE:  /Applications/Stata/ado/base/
    SITE:  /Applications/Stata/ado/site/
    PLUS:  ~/Library/Application Support/Stata/ado/plus/
PERSONAL:  ~/Library/Application Support/Stata/ado/personal/
OLDPLACE:  ~/ado/

From the command line on my Mac:

lisowskiw 18% ls -ld /Applications/Stata{/,/ado/*} ~/Library/Application\ Support/Stata/ado/*
drwxrwxr-x   9 root       admin   306 Mar 11 12:06 /Applications/Stata//
drwxrwxr-x  43 root       admin  1462 Mar 11 12:06 /Applications/Stata/ado/base/
drwxr-xr-x   4 lisowskiw  staff   136 Aug 22  2016 /Users/lisowskiw/Library/Application Support/Stata/ado/personal/
drwxr-xr-x  31 lisowskiw  staff  1054 Apr 13 15:41 /Users/lisowskiw/Library/Application Support/Stata/ado/plus/