Problem with Permission Elevation in Windows Vista

October 10, 2006 @ 11:13 pm- from Maui, Hawaii

Windows Vista allows you to raise permissions of an application automatically if the application 'looks' like a Setup or configuration application. Or you can run 'As Administrator' which gives you Admin permissions. There's a problem with this though - when this elevation occurs it's essentially switching users, so your local user store - the Documents directory - is no longer pointing at your user store but at the elevated user store which can be problematic.

I have an application - West Wind Web Connection for Visual FoxPro - that's a Web dev tool for FoxPro pretty much requires Administrative rights for initial configuration. So this app needs to configure IIS which downright requires admin access. Understandable. Surprisingly enough with a few tweaks and the IIS 6 Metabase compatibility the configuration routines using the IISAdmin tools work just fine as long as an Admin account is used. So far so good.

The main configuration application is conveniently called Setup.exe so Windows Vista will automatically try to elevate permissions to run as Administrator which is also good. The main application configuration works just fine it copies installation files etc. into a common folder and writes various configuration files in the install folder as well as the IIS Web virtual folder. All still good…

But…

One of the things that happens is that the application installs a set of user templates in the Visual Studio folder. These templates typically gets stored in the users Documents folder. The Documents folder is user specific so that the user gets a data location where she has full access to files with full read/write access.

But the problem is that when my application level configuration routine runs it’s been elevates as Administrator, so if I query for the Documents folder with ShGetSpecialFolder API I get Administrator’s private directory not the logged on users actual directory.

Now I have a problem. How do I find the original user’s logon directory?

This is an awkard situation – you need to run as an administrator, but you need to copy files into a directory for another user.

I can’t really see a good way from my ‘configuration’ application to figure even out who the user is that I’m supposed to be dealing with because as soon as I elevate I show up as the elevated user account (Administrator in this case). So GetUserName (or Sys(0) in VFP) returns Administrator. So there’s not even an easy way to hack your way into the right directory tree by manually creating path strings.

Now you might say why doesn’t your installer do this for you – the problem is that I create customized configurations for each new application that gets installed so the templates that are generated are usually not run through an installer but rather through this configuration routine.

The way it stands right now the user has to run things twice:

Run as Admin to configure IIS

Run as a normal user to add the templates

And well, that kinda sucks <g>…

Anybody see a way around this?

Posted in Vista Web Connection FoxPro

Feedback for this Weblog Entry

re: Problem with Permission Elevation in Windows Vista
by Kyle Alons October 12, 2006 @ 7:46 am

Install the template files to a folder under your install path, then on first run by a user, copy them to the user's My Documents path.

re: Problem with Permission Elevation in Windows Vista
by Rick Strahl October 12, 2006 @ 1:01 pm

Yeah I suppose that'll work. In fact that's what I have in the docs now. They have to run the main install to set up, and then run the Visual Studio configuration again from within the application.

The problem is these files get refreshed from time to time, so it's not something that can just happen automatically - it has to happen after users have made changed and usually when they create a new project which by itself will require running as Admin.

I'm looking to see to make that part at least work without Admin priviliges and that may work.

re: Problem with Permission Elevation in Windows Vista
by Michael Khalsa October 18, 2006 @ 11:51 am

I am also having problems in this area.

On first use, my program unzips and installs a few hundred files into a common files folder.
These files are meant to be updated from time to time.

The problem is that vista gets confused sometimes if it is accessing the newly created virtual store directory or the original program files\common files\ directory

For example, when unzipping the zip files (on first use), i first create a subdirectroy if it does not already exist.
Vista creates this for me in the virtual store. Then when it write the file using IO.File.

IO.File.WriteAllBytes(fullName, sr.ReadBytes(CInt(entry.Size)))

Vista attempts to write this into the original program files/common files/ directory, and of course it generates an error, because the sub directory was not created there.

I am running vista 5600, and i emailed microsoft about this, and they replied that it will be fixed in final version. But what the nature of that fix is, do not know; so in the interum in a holding state.

(I changed the permissions for the common files folder for full control by my non-admin user logon)

----

I think a solution would be to provide a default path to every application where files can be written to and accessed by all users, and the folder does not change (not a virtual folder).
Something like All Users\Program Data\App Name\...
Obviously this would have to work in both windows xp and vista.
and it would have to have a special folders environment enum for use in windows installer.

Does anyone know if something like this already exists?

-----

Another area this is going to present problems is in using update installers. I write code in my program that will check a site to see if an update is available (against a webservice, and if so, then for executables or program dll filesa web page is opened up and the user can download an installer.
I guess can jsut give the user instructions to run as administrator, so that the installer will update dll and exe files in the appropriate directories, but the whole thing is getting messy.
For content files, it downloads the serialized zips from webservice, unzips them, and installed them in the common folders if they are more recent versions (it does a version check first as well). Again if there is not a clear, non-changeable, understanding of what the common files folder is, it gets messy.
(these files are used by multiple apps, so it is a true use of 'common' files)
Anyone have ay ideas in this area.

Michael Khalsa
Crestone, CO

re: Problem with Permission Elevation in Windows Vista
by Rick Strahl October 18, 2006 @ 1:31 pm

Hi Michael,

The ShGetFolderPath has this flag:

CSIDL_COMMON_DOCUMENTS (0x002e)
The file system directory that contains documents that are common to all users. A typical paths is C:\Documents and Settings\All Users\Documents. Valid for Windows NT systems and Microsoft Windows 95 and Windows 98 systems with Shfolder.dll installed.

There are flags for most of the special folders in the 'Common area' so getting there is not a problem. Permissions on the other hand may be... If I go into Explorer and go to:

c:\users\all users\document and click on AppData I get access denied. This is another virtual folder it looks like that is redirected somewhere else, but not directly accessible. I REALLY, REALLY wish this shit would go away - The fact that you can't even telll where this folder is redirected to even with a full admin account is LAME, LAME, LAME!

In fact when it comes right down to it, even with a full Admin account I not figured out how to get to any other user's local data store. While normally that's OK, with a full admin account (with all admin restrictions removed in the policy) you should be able to get there to administer the machine. There probably is a way but whatever it is I haven't found it.

re: Problem with Permission Elevation in Windows Vista
by Rick Strahl October 18, 2006 @ 1:35 pm

One more thing - the All Users directory also doesn't have full rights for normal users, so this is not all that different from using Program Files except that there's probably no virtualization happening. So if you need to write files you need set directory permissions as well. If you do that you might as well do it in Program Files.

I suspect the thing to do for applications that require this is as part of the setup process add the appropriate permissions to the Program Files folder. Of course that's not easy without exposing the folder. The only way I could see this working is by using the generic Users group and giving full rights in that folder. That way you bypass virtualization and keep a central store though.

UGLY!

re: Problem with Permission Elevation in Windows Vista
by Alexandru Matei July 23, 2007 @ 2:56 am

Hello,

This topic tells something that might help to get the real logged on user name
not the elevated selected administrator account

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1670164&SiteID=1

1. Current logged on user is S (a standard user).
2. Finally, our program is launched with A's token (an administrator user).
3. In our code,
a. use WTSGetActiveConsoleSessionId() to get local interactive logged on user session (Console Session, may be 1-n on Vista)
b. use WTSQueryUserToken() with the console session id, it will returns token of S.
c. ImpersonateLoggedOnUser(hToken), impersonate user S.
d. GetUserName() to get S's name.
e. RevertToSelf(), resume to A's privilege.

re: Problem with Permission Elevation in Windows Vista
by Derek Best January 11, 2008 @ 2:13 pm

In response to Rick's original question, If I understand correctly the problem is:
You are logged in as user_A and you want to either elevate permissions or re-login as admin.
Having done so you want to run a setup propgram and place some settings in User_A's private folder, but you are not sure who user_A was.

First of all it seems a little unusual that any setup program woould only want to make changes to User_A's settings. I would think new settings would be common to all users... however I'm sure Rick knows his own requirements better than I.

There are a few different solutions I have tried. I definitely do NOT recommend turning off UAC. I think it's there for a good reason. First of all the c:\programdata\CompanyName\AppName folder is wide open for read/write. You could easily put a little ini file in there, and put a subkey in the ini called "LastUser". Every time a user opens the app, write the user name into that subkey. When an admin runs setup, have setup read that key to get the last user name. Then you can write whatever user_A settings you want into that user's CSIDL_LOCAL_APPDATA (which will be something like C:\Users\User_A\AppData\Local\Software\CompanyName\AppName\). The API call to get this folder (in case you don't know) is SHGetFolderPath.

Because of the easy access to c:\programdata\CompanyName\AppName a lot of developers I know are using it for all kinds of things, even the app itself. The advantage of putting the app there is - all users can read and write to the app folder with ease. The disadvantage is exactly the same thing. That's for you to decide.

Another thing you can do is to write settings in HKLM/Software/Company/App. I know Vista does not allow users to write there -- and that is probably a good security concept. But it does if you specifically set user-write permissions to that particular subkey as a function of the app install pprogram. I can see no security risk in an app being allowed to write to its own little subkey. So put the last-user name in there, and have the setup program read it.

Hope these suggestions are helpful.
Derek

clonedvdmovie
by clonedvdmovie March 27, 2008 @ 6:21 pm

This strip reminded me of my Cryptology class for which I was the TA with an enrollment of 70 students. Weekly assignments were horrible as I spent more time grading them than the students may have spent on searching for the solutions. Exams were the worst with me having to evaluate their solutions to award partial points. It feel so good to see the right answers but these partial points we a killer. One had to go through all the steps and spot the error and then award some points for the number of correct steps.

re: Problem with Permission Elevation in Windows Vista
by Frank April 02, 2008 @ 9:27 pm

Vista does not use my documents to store app data.
look at ProgramData