Hello,

Vista and higher problem :-(

I try to run my application in a least privilege scenario.

My installer (Inno Setup) installs a database file to ProgramData 
(=CommonAppData) using the "privileges=Admin" flag.

Because it gets virtualized when a user uses it, I let my app copy the 
database from CommonAppData to the user's personal folder first and have 
it working with this "personalized" version. After copying it, the app 
writes the file size to a text file.

Now when I deploy an update with an updated version of my database, the 
installer installs the updated version of my database over the existing 
database under ProgramData/ CommonAppData.

When the app is then started, it will notice that the database size has 
changed and will copy the new database to the private folder.

I thought this was foolsafe, but now a user has problems that make the 
think that he is still using the older version of my database.

Does anybody see any obvious flaws in my thinking?

The user (he is running Vista or Windows 7, 64 bit) tells me that when 
he runs the app as an admin, everything is fine, and the app seems to 
use the latest database.
However, I would like to understand what's going wrong, and I don't want 
to run my app as an admin because I don't know if this causes more 
problems that I need to fix.

I often read that
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
was the solution.
I don't want to mess with this because I am not sure what it does. 
Doesn't this display the UAC if the user is not an admin?

Thanks a lot
Dimi

"Dimitri Kowaletschew" <dimi.k@yahoo.com> wrote in message 
news:%23$sqrnxcKHA.6096@TK2MSFTNGP02.phx.gbl...
> When the app is then started, it will notice that the database size has 
> changed and will copy the new database to the private folder.

What is this "private folder"?

What you need to do is add the following to your script:

[Dirs]
Name: {commonappdata}\MyCompany\MyProgram; Permissions: authusers-full

Then don't write to anything in "Program Files" and similar locations. This 
should be fine for most cases, and you don't need to add a manifest.

However, after applying the above [Dirs] entry, the user would now see only 
the copy that is installed in the correct location(under <commonappdata>). 
However, if Windows previously virtualized the files, and you want to copy 
over the virtual copy back to the correct location, then do the following 
from your app:

- Check that the OS is Vista or after.
- Copy the files from:

<CSIDL_LOCAL_APPDATA>\VirtualStore\ProgramData\MyOlderSubFolderName\MyFile.ini

To:

<CSIDL_COMMON_APPDATA>\MyCompany\MyProgram\MyFile.ini


You don't need to add a manifest, but if you do, use "asInvoker". This 
disables virtualization, but your app would get access denied error when 
trying to write to "Program Files" and similar locations. If you use [Dirs] 
entry above, no virtualization occurs whether you have a manifest or not.

Also, see "Virtualization is disabled for" in this page:

Windows Vista Application Development Requirements for User Account Control 
Compatibility
http://msdn.microsoft.com/en-us/library/bb530410.aspx

Quote:

Virtualization is only enabled for:

* 32 bit interactive processes
* Administrator writeable file/folder and registry keys

Virtualization is disabled for:

* 64 bit processes
* Non-interactive processes
* Processes that impersonate
* Kernel mode callers
* Executables that have a requestedExecutionLevel

Virtualization and roaming:

* Virtualization files/folder and registry keys do not roam (see roaming 
profiles)
* Associated with global objects that do not roam

Hello Nobody,

1.
Can you please explain what

> [Dirs]
> Name: {commonappdata}\MyCompany\MyProgram; Permissions: authusers-full
> 

does in contrast to

[Files]
Source: "C:\Dev\Projects\ProjectXY\FrequentlyUpdatedDatabase.db"; 
DestDir: {commonappdata}\ProjectXY\DB; Flags: ignoreversion; Attribs: hidden

2.
> Then don't write to anything in "Program Files" and similar locations. 

By "Program Files" you mean "{commonappdata}", don't you?
If not, can you please explain more?

3.
Where should the setup install the database? By [Dirs] (...) I only 
create a folder...
Should the app copy the file over to the user's "private folders"? By 
"Private folders" I mean something like
CSIDL_LOCAL_APPDATA

Thanks a lot
Dimi

"Dimitri Kowaletschew" <dimi.k@yahoo.com> wrote in message 
news:OohVdq4cKHA.5568@TK2MSFTNGP02.phx.gbl...
> About your Dir flags...
> I don't understand how this can be...
> There are dozens and dozens of discussions about where one could store 
> shared data, and all ended up with weird solutions.
> Now you say that a simple flag would do the job. I cannot believe it yet.

Yes. There is a ton of code behind that simple flag. The Package and 
Deployment Wizard doesn't have something like that built-in. You could check 
this sample if you want to know how it's done:

How to use low-level access control APIs from Visual Basic
http://support.microsoft.com/kb/316440

Another way for PDW users is to use SetACL, which is open source. Here is 
the command line:

SetACL.exe -on "<CSIDL_COMMON_APPDATA>\MyCompany\MyProgram" -ot file -actn 
ace -ace "n:S-1-5-11;p:full;s:y;i:io,so,sc;m:set;w:dacl" -actn clear -clr 
"dacl,sacl" -actn setprot -op "dacl:p_c;sacl:p_c"

You need to substitute <CSIDL_COMMON_APPDATA> with the value from 
SHGetSpecialFolderLocation(CSIDL_COMMON_APPDATA). SetACL can be downloaded
from here:

http://setacl.sourceforge.net/

"S-1-5-11" in the command line above is the SID(Security ID) for 
"Authenticated Users" group. You can see the list of SID's here:

Well-known security identifiers in Windows operating systems
http://support.microsoft.com/kb/243330

"Nobody" <nobody@nobody.com> wrote in message 
news:%23WLPxd6cKHA.4952@TK2MSFTNGP06.phx.gbl...
| 2 - On program startup, and without any flags, copy the samples from
| "Program Files" or CSIDL_COMMON_APPDATA to the user's "My
| Documents\MyProgram\Samples" folder if not already copied, so when he 
edits
| the files, there is no problem in saving them. There is no need to add a
| manifest in this case, but if you suspect that the user might open the
| copies under "Program Files" or CSIDL_COMMON_APPDATA, then use asInvoker
| manifest to insure that your app gets access denied error instead of 
Windows
| virtualizing the files.

I tried the "copy from CSIDL_COMMON_APPDATA to User data" at program starup 
originally.  Some users kept reporting file copy errors, even though I could 
never reproduce them (and it wasn't always on Vista, it was XP too).  It got 
to be enough of a problem that I wrote the class that checks for Per User 
data first and if it doesn't find the file in question, it reads the 
"master" file installed in All Users, where the installer put it (and if 
it's not, errors out gracefully).  And as I said, all saving from that point 
forward is Per User.  No writing is ever done to the master file.  I guess 
the same could be done from Program Files, but the problem I foresaw that 
was curious users attempting to be crafty and editing thier own data files 
manually and then bothering me when it didn't work (it's happened).  The 
class completely replaces app.path for file IO.  I guess I should post it 
someplace so others can benefit.  It's been 100% more reliable than messing 
with copy routines.

The one gotcha in all of this of course is running the app in the VB IDE 
under Vista if the VB IDE is ticked to run as admin.  In that scenario, one 
does not see file write errors when writing to locations that should not be 
written to, because with VB running as admin, the OS will let it.  Once the 
EXE is compiled and the admin flag isn't there, then errors occur.  I've 
seen folks completely overlook that who then wondered why the program wasn't 
working properly.  :-) 

"Nobody" <nobody@nobody.com> wrote in message 
news:u4uZ$$6cKHA.1648@TK2MSFTNGP05.phx.gbl...

| According to the following article, when you don't use CSIDL_FLAG_CREATE 
and
| the folder doesn't exist, SHGetFolderPath fails and the buffer remains
| unchanged. So this might be the reason. I don't know if this also applies 
to
| SHGetSpecialFolderLocation(). Interestingly this is not well documented in
| MSDN.
|
| How To Use the SHGetFolderPath Function from Visual Basic
| http://support.microsoft.com/kb/252652
|
| Even GetTempPath() doesn't necessarily return an existing folder, so in 
this
| case you must create it if needed.
|
| Another reason could be some security software locking down the machine.

The routine had a check for existing folders (%USERAPPDATA%\Company first, 
and then %USERAPPDATA%\Company\App last).  I assumed super mega security 
applications as well.  It got to be too much of a PITA to figure out, so I 
ditched it.  :-)

You should see some these support requests I get.  My homemade sys info 
utility lists all running processes, and you'd be surprised how many apps 
are installed into %USERAPPDATA% and run from that location.  Sometimes 
malware, but mostly games.  I find it hard to believe those developers still 
have a job, or got the job to begin with.  Lazy, sloppy and badly written. 

Dimitri Kowaletschew <dimi.k@yahoo.com> wrote:

>My installer (Inno Setup) installs a database file to ProgramData 
>(=CommonAppData) using the "privileges=Admin" flag.

Why not to the users App Data and be done with it.

What kind of database file?  If Access there are ways and means of
updating the tables, indexes and relationships in place.

>Now when I deploy an update with an updated version of my database, the 
>installer installs the updated version of my database over the existing 
>database under ProgramData/ CommonAppData.

Set that flag so it doesn't overwrite the database.    

Tony
-- 
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files 
  updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/

I don't install to user's data directly because then I get angry mails 
why the application doesn't work when the user is switched.


Tony Toews [MVP] wrote:
> Dimitri Kowaletschew <dimi.k@yahoo.com> wrote:
> 
>> My installer (Inno Setup) installs a database file to ProgramData 
>> (=CommonAppData) using the "privileges=Admin" flag.
> 
> Why not to the users App Data and be done with it.
> 
> What kind of database file?  If Access there are ways and means of
> updating the tables, indexes and relationships in place.
> 
>> Now when I deploy an update with an updated version of my database, the 
>> installer installs the updated version of my database over the existing 
>> database under ProgramData/ CommonAppData.
> 
> Set that flag so it doesn't overwrite the database.    
> 
> Tony

Yes, that's what I meant... it's not a piece of cake, and I didn't want 
to fiddle around with external programs.
The combination of "asInvoker" and the Dir flag is really what I needed!!

Now I am trying to programmatically remove the previous virtualizations.
I haven't been able to find a constant for that.
Is it always 
"ROOT:\Users\<USERNAME>\AppData\Local\VirtualStore\ProgramData\<APPNAME>\"??

Thanks a lot!
Dimi

Nobody wrote:
> "Dimitri Kowaletschew" <dimi.k@yahoo.com> wrote in message 
> news:OohVdq4cKHA.5568@TK2MSFTNGP02.phx.gbl...
>> About your Dir flags...
>> I don't understand how this can be...
>> There are dozens and dozens of discussions about where one could store 
>> shared data, and all ended up with weird solutions.
>> Now you say that a simple flag would do the job. I cannot believe it yet.
> 
> Yes. There is a ton of code behind that simple flag. The Package and 
> Deployment Wizard doesn't have something like that built-in. You could check 
> this sample if you want to know how it's done:
> 
> How to use low-level access control APIs from Visual Basic
> http://support.microsoft.com/kb/316440
> 
> Another way for PDW users is to use SetACL, which is open source. Here is 
> the command line:
> 
> SetACL.exe -on "<CSIDL_COMMON_APPDATA>\MyCompany\MyProgram" -ot file -actn 
> ace -ace "n:S-1-5-11;p:full;s:y;i:io,so,sc;m:set;w:dacl" -actn clear -clr 
> "dacl,sacl" -actn setprot -op "dacl:p_c;sacl:p_c"
> 
> You need to substitute <CSIDL_COMMON_APPDATA> with the value from 
> SHGetSpecialFolderLocation(CSIDL_COMMON_APPDATA). SetACL can be downloaded
> from here:
> 
> http://setacl.sourceforge.net/
> 
> "S-1-5-11" in the command line above is the SID(Security ID) for 
> "Authenticated Users" group. You can see the list of SID's here:
> 
> Well-known security identifiers in Windows operating systems
> http://support.microsoft.com/kb/243330
> 
> 
> 

"Dimitri Kowaletschew" <dimi.k@yahoo.com> wrote in message 
news:OcEBwp$cKHA.5472@TK2MSFTNGP02.phx.gbl...
> Yes, that's what I meant... it's not a piece of cake, and I didn't want to 
> fiddle around with external programs.
> The combination of "asInvoker" and the Dir flag is really what I needed!!
>
> Now I am trying to programmatically remove the previous virtualizations.
> I haven't been able to find a constant for that.
> Is it always 
> "ROOT:\Users\<USERNAME>\AppData\Local\VirtualStore\ProgramData\<APPNAME>\"??

Use CSIDL_LOCAL_APPDATA to get "ROOT:\Users\<USERNAME>\AppData\Local" part. 

On 02/12/2009 20:03, Dimitri Kowaletschew wrote:
> About your Dir flags...
> I don't understand how this can be...
> There are dozens and dozens of discussions about where one could store
> shared data, and all ended up with weird solutions.
> Now you say that a simple flag would do the job. I cannot believe it yet.

It's only really complicated by people that have completely the wrong 
idea and refuse to accept that the correct solution is really simple :)
(It happens at least once a week!)

-- 
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team

iCode Systems

On 03/12/2009 02:32, Tony Toews [MVP] wrote:
> Dimitri Kowaletschew<dimi.k@yahoo.com>  wrote:
>
>> My installer (Inno Setup) installs a database file to ProgramData
>> (=CommonAppData) using the "privileges=Admin" flag.
>
> Why not to the users App Data and be done with it.
>
> What kind of database file?  If Access there are ways and means of
> updating the tables, indexes and relationships in place.

The setup user's app data folder may not be the current user's app data 
folder.
Even if it is the same, it means it won;t work for any other user.

-- 
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team

iCode Systems

"C. Kevin Provance" <*@*.*> wrote in message 
news:OpYyR77cKHA.2184@TK2MSFTNGP04.phx.gbl...
> The routine had a check for existing folders (%USERAPPDATA%\Company first,
> and then %USERAPPDATA%\Company\App last).  I assumed super mega security
> applications as well.  It got to be too much of a PITA to figure out, so I
> ditched it.  :-)
>
> You should see some these support requests I get.  My homemade sys info
> utility lists all running processes, and you'd be surprised how many apps
> are installed into %USERAPPDATA% and run from that location.  Sometimes
> malware, but mostly games.  I find it hard to believe those developers 
> still
> have a job, or got the job to begin with.  Lazy, sloppy and badly written.

Actually this is one of the solutions Microsoft suggests to developers of 
games and other frequently self-updating software meant to be install 
per-user.

Starting in Windows 7 this is even officially sanctioned as part of per-user 
installation and dual-mode packaging for Windows Installer 5:

FOLDERID_UserProgramFiles: �%LocalAppData%\Programs�
FOLDERID_UserProgramFilesCommon: �%LocalAppData%\Programs\Common�

The idea is to permit standard users to perform per-user installs for 
themselves (without requiring over the shoulder elevation).  To use this 
with VB6 programs you normally must use reg-free COM or else per-user 
component registration (to HKCU).

The downside is that you lose some protection against machine infection. 
However no software installed this way should ever run elevated anyway, 
limiting the scope of damage malware might cause.  Admins like this because 
it saves them handling every software install users might need while again 
limiting the scope of damage.  Worst case they wipe the entire user profile 
but they never have to go on a malware hunt or install a clean image.

I think you're still a bit behind the curve on this stuff, but I agree it 
seems to be a fast-moving target.

"Nobody" <nobody@nobody.com> wrote in message 
news:u4uZ$$6cKHA.1648@TK2MSFTNGP05.phx.gbl...
> According to the following article, when you don't use CSIDL_FLAG_CREATE 
> and the folder doesn't exist, SHGetFolderPath fails and the buffer remains 
> unchanged. So this might be the reason. I don't know if this also applies 
> to SHGetSpecialFolderLocation(). Interestingly this is not well documented 
> in MSDN.
>
> How To Use the SHGetFolderPath Function from Visual Basic
> http://support.microsoft.com/kb/252652

I was debugging why SHGetSpecialFolderLocation() fails with invalid 
parameter error when I specify "CSIDL_COMMON_APPDATA Or CSIDL_FLAG_CREATE". 
It turned out that I had the following line:

Public Const CSIDL_FLAG_CREATE As Long = &H8000

It came from ApiViewer 2004. After adding "&" at the end, it worked fine. VB 
was obviously considering &H8000 as Integer(-32767), then converts it to 
Long, this leads to &HFFFF8000, which is -32767 in Long, but it was not the 
intended binary value. If you have that declaration, check it out to see if 
it was contributing to the problem that you were having.

"Bob Riemersma" <nospam@nil.net> wrote:

>Actually this is one of the solutions Microsoft suggests to developers of 
>games and other frequently self-updating software meant to be install 
>per-user.
>
>Starting in Windows 7 this is even officially sanctioned as part of per-user 
>installation and dual-mode packaging for Windows Installer 5:

Thanks for posting this.  I could be using this concept in the near
future myself.

Tony
-- 
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files 
  updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/

"Tony Toews [MVP]" <ttoews@telusplanet.net> wrote in message 
news:po2jh556jmt4ga5f84niljc7pn1cca1j86@4ax.com...
> "Bob Riemersma" <nospam@nil.net> wrote:
>
>>Actually this is one of the solutions Microsoft suggests to developers of
>>games and other frequently self-updating software meant to be install
>>per-user.
>>
>>Starting in Windows 7 this is even officially sanctioned as part of 
>>per-user
>>installation and dual-mode packaging for Windows Installer 5:
>
> Thanks for posting this.  I could be using this concept in the near
> future myself.

Off topic:

Windows Installer 4.5 requires XP+SP2+. I am not sure what Windows Installer 
5 requires. Windows Installer 4 came with Vista and is not redistributable, 
but 4.5 is.

Windows Installer 4.5 is available
http://support.microsoft.com/KB/942288

Released Versions of Windows Installer
http://msdn.microsoft.com/en-us/library/aa371185(VS.85).aspx