Is there a shared folder in Windows to which non-elevated users have write access?

Question

I know that commonappdata (All Users) can hold system-wide application settings, but under Vista/7 non-elevated users can't write to that directory.

Is there a folder which is shared among users and any non-admin user can write to it?

Here is why I need this: My app is installed in PF directory by an Inno Setup installer with elevated rights. Then when the actual non-admin user runs the program, it copies its settings to the user's AppData directory using another non-elevated Inno Setup installer. Upon deinstalling the program (initiated by the system-wide installer with admin rights) I want to uninstall the program's files from each users' AppData directory.

I can think of two solutions: 1. Getting a list of Windows users and iterating through their AppData dirs (seems way too complicated) 2. Storing the paths to the uninstallers in the above mentioned common user data directory.

Any ideas?

Thanks!

Executant

Answer 1

"Shared Documents" Directory in Windows XP

C:\Documents and Settings\All Users\Documents

Or,

%ALLUSERSPROFILE%\Documents

Corresponding directory in Vista/7

C:\Users\Public

Or,

%PUBLIC%\Documents

But what you are really looking for, is the KNOWNFOLDERID value of FOLDERID_PublicDocuments (legacy CSIDL_COMMON_DOCUMENTS). The SHGetFolderPath function can then get you the path.

Or an easier VBScript alternative, but I'm not sure how reliable this is across OS versions:

Const CSIDL_COMMON_DOCUMENTS = &h2e 
Set oShell = CreateObject("Shell.Application")
Wscript.Echo oShell.Namespace(CSIDL_COMMON_DOCUMENTS).Self.Path

I think NameSpace doesn't accept that particular constant. So you might be able to take COMMONAPPDATA = &H23 and then use its parent. But that's not very clean or internationalized:

Wscript.Echo oShell.NameSpace(&h23).ParentFolder.Self.Path & "\Documents"

But since you are using Inno Setup, you should really be using the {commondocs} Shell Folder Constant and make it easy for yourself.

Lowther

Answer 2

The user owns the document folder. Expect files to be copied, moved, deleted or edited with another program if you put something there, because of the visibility to the user.

I suggest you to create a folder under the common application data (CSIDL_COMMON_APPDATA or FOLDERID_ProgramData) in your installer with a security descriptor that allows everyone access.

E.g.

[Dirs]
Name: "{commonappdata}\productname";Permissions:everyone-modify;

Simaroubaceous

Answer 3

Would stuff under C:\Users\Public\ qualify for what you need?

Responsible

Isn't that available only on Vista and above? I need a solution for XP too! – Executant

@Steve: I believe XP has a Shared Documents folder in My Computer, not sure what the full path to it is. It's intended for multi-user local access. – Responsible

Answer 4

Solution 1 looks quite reasonable to me. So every user control their and only their installation, and you control the central shared installation.

For solution 2 you can create a write-allowed folder in a well-defined location so that your installer knows about it, or use a registry key for the same purpose. But keep in mind that this may create a security hole because anyone could tamper with uninstall paths of other users.

Riverine

But how do I go about realizing solution 2? Where is a path under Windows which is independent of userappdata dirs and normal non-elevated users have write-access to it? – Executant

Your installer that runs with admin privileges can create such a folder, it has enough rights to do so. Probably this must be a subfolder somewhere inside the common (admin-run) installation folder. – Riverine

Could you point me to somewhere where they explain how to do this in practice? I suppose even if I do this, the installer will have to iterate through all user accounts and grant permission to them one by one? :-) – Executant

Either that, or just grant write permission to this folder to 'Users' group (or what do they call the group where every valid interactive user belongs). That was my original idea. – Riverine

Thanks, but I still don't know how to grant permissions from my program, can you point me to any example code? – Executant