is there some location (c.f. [CommonAppData]) where even limited users can modify/write files?

I'm having trouble porting something to Vista because my C# assembly (in the
global assembly cache) needs to have a location where it can
read/write/modify a file.

With Administrator accounts, it works fine, but with a limited account it
can't write to the location where the file is stored (which originally was
in C:\Program Files\Common Files...).

I tried moving it to [CommonAppData], but on Vista (at least), the limited
account doesn't have priviledge to modify files in that location (i.e.
C:\Users\All Users\... or C:\ProgramData\... I can't tell which... there are
duplicate copies in both locations).

Is there anywhere I can put a data file so that all users wil have
modify/write priviledge?

Thanks,
Bob

Well - thats kind of the idea of a normal user - you cannot do anything that
could affect another user on the same system - isolation...


That said - in Vista there are these new shared/public folder (for images
and other stuff) - haven't played around with them - but that might be worth
having a closer look...


-----
Dominick Baier (http://www.leastprivilege.com)

Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp)

> I'm having trouble porting something to Vista because my C# assembly
> (in the global assembly cache) needs to have a location where it can
> read/write/modify a file.
>
> With Administrator accounts, it works fine, but with a limited account
> it can't write to the location where the file is stored (which
> originally was in C:\Program Files\Common Files...).
>
> I tried moving it to [CommonAppData], but on Vista (at least), the
> limited account doesn't have priviledge to modify files in that
> location (i.e. C:\Users\All Users\... or C:\ProgramData\... I can't
> tell which... there are duplicate copies in both locations).
>
> Is there anywhere I can put a data file so that all users wil have
> modify/write priviledge?
>
> Thanks,
> Bob

Bob

Vista uses Virtualization for older applications that need full write
permissions.

The path for the data file is C:\Users\username\AppData\Local\Virtual
Store\Program Files\program name.

See these articles for more information.

Developer Best Practices and Guidelines for Applications in a Least
Privileged Environment:
http://msdn2.microsoft.com/en-us/lib...otvista_topic4

User Account Control:
http://msdn2.microsoft.com/en-us/library/aa511445.aspx




--

Ronnie Vernon
Microsoft MVP
Windows Shell/User


"Bob Eaton" <> wrote in message
news:...
> I'm having trouble porting something to Vista because my C# assembly (in
> the global assembly cache) needs to have a location where it can
> read/write/modify a file.
>
> With Administrator accounts, it works fine, but with a limited account it
> can't write to the location where the file is stored (which originally was
> in C:\Program Files\Common Files...).
>
> I tried moving it to [CommonAppData], but on Vista (at least), the limited
> account doesn't have priviledge to modify files in that location (i.e.
> C:\Users\All Users\... or C:\ProgramData\... I can't tell which... there
> are duplicate copies in both locations).
>
> Is there anywhere I can put a data file so that all users wil have
> modify/write priviledge?
>
> Thanks,
> Bob
>
>

Thanks Ronnie, but virtualization won't help me: the whole reason for trying
to find somewhere shared (both in the registry and in the file system) that
I can write information is so that other uses will pick up changes made. If
user a tries to change the registry key (e.g. which we use to point to the
newest data store filespec), then s(he) will presumably be able to access
the key subsequently and get the path (because it got virtualized, and
subsequent reads by that user will go to the virtual version first).
However, other users will end up reading the HKLM version of the key which
will now be out of date.

I can get around the need to change the registry key (by just always using
the same filename and have it set by the installer which has adminstrator
privileges), but not the need to modify a file on the file system, which any
potential users need to be able to do. Again, if file virtualization
happens, then the other users won't pick up the change.

I appreciate the fact that "limited user" means don't hurt anyone else, but
I'm just surprised that there's *no* system location where this is allowed.
There are "Public" folders, but no "Public AppData", which I think there
should be.

Ultimately, I think we're going to have a work-around by having the
installer change the permissions on the [CommonAppData]<companyName>\<app
folder> folder to give "Full Access" permission for "Everyone". [the
installer developer says he's able to do this].

However, something else is bothering me: the assembly that does the reading
and
writing of the registry key and files in [CommonAppData] is in the global
assembly cache. According to MSDN magazine (Nov 05), "The GAC is Full
Trust". So here's what confuses me: The installer needs administrator
privileges in order to even install that assembly in the GAC, it needed to
be strong named to go in the GAC, the user had to "Fully trust" it during
during installation... so why with all this doesn't it have permission to
write registry keys when it is used by a client application.

I even tried to use:

RegistryPermission rp = new
RegistryPermission(RegistryPermissionAccess.Create , strRegKey);

rp.Assert();

in the GAC assembly to fake the system out that it has permission and not
check the apps higher up the stack, but it just throws a Security Exception
error.

Is this because DLLs (even in the GAC) can't use SecurityPermissions?

Thanks,

Bob





"Ronnie Vernon MVP" <> wrote in message
news:...
> Bob
>
> Vista uses Virtualization for older applications that need full write
> permissions.
>
> The path for the data file is C:\Users\username\AppData\Local\Virtual
> Store\Program Files\program name.
>
> See these articles for more information.
>
> Developer Best Practices and Guidelines for Applications in a Least
> Privileged Environment:
> http://msdn2.microsoft.com/en-us/lib...otvista_topic4
>
> User Account Control:
> http://msdn2.microsoft.com/en-us/library/aa511445.aspx
>
>
>
>
> --
>
> Ronnie Vernon
> Microsoft MVP
> Windows Shell/User
>
>
> "Bob Eaton" <> wrote in message
> news:...
>> I'm having trouble porting something to Vista because my C# assembly (in
>> the global assembly cache) needs to have a location where it can
>> read/write/modify a file.
>>
>> With Administrator accounts, it works fine, but with a limited account it
>> can't write to the location where the file is stored (which originally
>> was in C:\Program Files\Common Files...).
>>
>> I tried moving it to [CommonAppData], but on Vista (at least), the
>> limited account doesn't have priviledge to modify files in that location
>> (i.e. C:\Users\All Users\... or C:\ProgramData\... I can't tell which...
>> there are duplicate copies in both locations).
>>
>> Is there anywhere I can put a data file so that all users wil have
>> modify/write priviledge?
>>
>> Thanks,
>> Bob
>>
>>
>

I would say that changing the ACL on a common directory is no "workaround"
- but the right way of doing it. That's what ACLs are for - either set the
ACL to a group of users or use "authenticated users".

Full Trust refers to Code Access Security - this has nothing to do with OS
level permissions.


-----
Dominick Baier (http://www.leastprivilege.com)

Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp)

> Thanks Ronnie, but virtualization won't help me: the whole reason for
> trying to find somewhere shared (both in the registry and in the file
> system) that I can write information is so that other uses will pick
> up changes made. If user a tries to change the registry key (e.g.
> which we use to point to the newest data store filespec), then s(he)
> will presumably be able to access the key subsequently and get the
> path (because it got virtualized, and subsequent reads by that user
> will go to the virtual version first). However, other users will end
> up reading the HKLM version of the key which will now be out of date.
>
> I can get around the need to change the registry key (by just always
> using the same filename and have it set by the installer which has
> adminstrator privileges), but not the need to modify a file on the
> file system, which any potential users need to be able to do. Again,
> if file virtualization happens, then the other users won't pick up the
> change.
>
> I appreciate the fact that "limited user" means don't hurt anyone
> else, but I'm just surprised that there's *no* system location where
> this is allowed. There are "Public" folders, but no "Public AppData",
> which I think there should be.
>
> Ultimately, I think we're going to have a work-around by having the
> installer change the permissions on the
> [CommonAppData]<companyName>\<app
>
folder>> folder to give "Full Access" permission for "Everyone". [the
folder>>
> installer developer says he's able to do this].
>
> However, something else is bothering me: the assembly that does the
> reading
> and
> writing of the registry key and files in [CommonAppData] is in the
> global
> assembly cache. According to MSDN magazine (Nov 05), "The GAC is Full
> Trust". So here's what confuses me: The installer needs administrator
> privileges in order to even install that assembly in the GAC, it
> needed to
> be strong named to go in the GAC, the user had to "Fully trust" it
> during
> during installation... so why with all this doesn't it have permission
> to
> write registry keys when it is used by a client application.
> I even tried to use:
>
> RegistryPermission rp = new
> RegistryPermission(RegistryPermissionAccess.Create , strRegKey);
> rp.Assert();
>
> in the GAC assembly to fake the system out that it has permission and
> not check the apps higher up the stack, but it just throws a Security
> Exception error.
>
> Is this because DLLs (even in the GAC) can't use SecurityPermissions?
>
> Thanks,
>
> Bob
>
> "Ronnie Vernon MVP" <> wrote in message
> news:...
>
>> Bob
>>
>> Vista uses Virtualization for older applications that need full write
>> permissions.
>>
>> The path for the data file is C:\Users\username\AppData\Local\Virtual
>> Store\Program Files\program name.
>>
>> See these articles for more information.
>>
>> Developer Best Practices and Guidelines for Applications in a Least
>> Privileged Environment:
>> http://msdn2.microsoft.com/en-us/lib...accprotvista_t
>> opic4
>>
>> User Account Control:
>> http://msdn2.microsoft.com/en-us/library/aa511445.aspx
>> --
>>
>> Ronnie Vernon
>> Microsoft MVP
>> Windows Shell/User
>> "Bob Eaton" <> wrote in message
>> news:...
>>
>>> I'm having trouble porting something to Vista because my C# assembly
>>> (in the global assembly cache) needs to have a location where it can
>>> read/write/modify a file.
>>>
>>> With Administrator accounts, it works fine, but with a limited
>>> account it can't write to the location where the file is stored
>>> (which originally was in C:\Program Files\Common Files...).
>>>
>>> I tried moving it to [CommonAppData], but on Vista (at least), the
>>> limited account doesn't have priviledge to modify files in that
>>> location (i.e. C:\Users\All Users\... or C:\ProgramData\... I can't
>>> tell which... there are duplicate copies in both locations).
>>>
>>> Is there anywhere I can put a data file so that all users wil have
>>> modify/write priviledge?
>>>
>>> Thanks,
>>> Bob

"Dominick Baier" <dbaier@pleasepleasenospam_leastprivilege.com> wrote in
message news: m...

>I would say that changing the ACL on a common directory is no
>"workaround" - but the right way of doing it. That's what ACLs are for -
>either set the ACL to a group of users or use "authenticated users".

I agree. Vista uses the security mode of give out the least possible amount
of permissions for security. If you need different access to a folder that
you created in the appropriate location for shared data then change the ACLs
(for that folder and subfolders only) during the program installation.

--
Kerry Brown
Microsoft MVP - Shell/User
http://www.vistahelp.ca

My original concern is that in order to make this work, I didn't want to
have to tell the user, "Log in as administrator, go to such-and-such folder,
right-click and choose Properties, Security..." and I don't personally know
how to set ACLs in an installer.

Is it possible to modify ACLs during installation with VS.Net (2005) setup
projects (merge module or msi)?

Is it possible to modify ACLs during run-time execution of a GAC DLL
assembly? e.g. is it possible to call some code which will result in the "do
you want to allow this" dialog being pop'd up and if the user says "Accept",
that then gives me administrator privileges to do whatever I want?

For example, could someone give me a 3-5 sentence explanation why what I
said earlier didn't work?

+-------------
I even tried to use:

RegistryPermission rp = new
RegistryPermission(RegistryPermissionAccess.Create , strRegKey);

rp.Assert();

in the GAC assembly to fake the system out that it has permission and not
check the apps higher up the stack, but it just throws a Security Exception
error.

Is this because DLLs (even in the GAC) can't use SecurityPermissions?

+-------------

I appologize if these are basic questions, but I've looked at security for
several days now and it isn't becoming clearer.

Bob



"Kerry Brown" <*a*m> wrote in message
news:u$...
> "Dominick Baier" <dbaier@pleasepleasenospam_leastprivilege.com> wrote in
> message news: m...
>
>>I would say that changing the ACL on a common directory is no
>>"workaround" - but the right way of doing it. That's what ACLs are for -
>>either set the ACL to a group of users or use "authenticated users".
>
> I agree. Vista uses the security mode of give out the least possible
> amount of permissions for security. If you need different access to a
> folder that you created in the appropriate location for shared data then
> change the ACLs (for that folder and subfolders only) during the program
> installation.
>
> --
> Kerry Brown
> Microsoft MVP - Shell/User
> http://www.vistahelp.ca
>
>

I'm not a programmer. You could try the MSDN forums.

http://forums.microsoft.com/msdn/default.aspx?siteid=1

--
Kerry Brown
Microsoft MVP - Shell/User
http://www.vistahelp.ca


"Bob Eaton" <> wrote in message
news:...
> My original concern is that in order to make this work, I didn't want to
> have to tell the user, "Log in as administrator, go to such-and-such
> folder, right-click and choose Properties, Security..." and I don't
> personally know how to set ACLs in an installer.
>
> Is it possible to modify ACLs during installation with VS.Net (2005) setup
> projects (merge module or msi)?
>
> Is it possible to modify ACLs during run-time execution of a GAC DLL
> assembly? e.g. is it possible to call some code which will result in the
> "do
> you want to allow this" dialog being pop'd up and if the user says
> "Accept",
> that then gives me administrator privileges to do whatever I want?
>
> For example, could someone give me a 3-5 sentence explanation why what I
> said earlier didn't work?
>
> +-------------
> I even tried to use:
>
> RegistryPermission rp = new
> RegistryPermission(RegistryPermissionAccess.Create , strRegKey);
>
> rp.Assert();
>
> in the GAC assembly to fake the system out that it has permission and not
> check the apps higher up the stack, but it just throws a Security
> Exception
> error.
>
> Is this because DLLs (even in the GAC) can't use SecurityPermissions?
>
> +-------------
>
> I appologize if these are basic questions, but I've looked at security for
> several days now and it isn't becoming clearer.
>
> Bob
>
>
>
> "Kerry Brown" <*a*m> wrote in message
> news:u$...
>> "Dominick Baier" <dbaier@pleasepleasenospam_leastprivilege.com> wrote in
>> message news: m...
>>
>>>I would say that changing the ACL on a common directory is no
>>>"workaround" - but the right way of doing it. That's what ACLs are for -
>>>either set the ACL to a group of users or use "authenticated users".
>>
>> I agree. Vista uses the security mode of give out the least possible
>> amount of permissions for security. If you need different access to a
>> folder that you created in the appropriate location for shared data then
>> change the ACLs (for that folder and subfolders only) during the program
>> installation.
>>
>> --
>> Kerry Brown
>> Microsoft MVP - Shell/User
>> http://www.vistahelp.ca
>>
>>
>
>
>

Yes,

you can write a custom action in the VS installation project - the APIs to
change ACLs can be found in System.Security.AccessControl.

e.g. Directory.GetAccessControl(..)


-----
Dominick Baier (http://www.leastprivilege.com)

Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp)

> My original concern is that in order to make this work, I didn't want
> to have to tell the user, "Log in as administrator, go to
> such-and-such folder, right-click and choose Properties, Security..."
> and I don't personally know how to set ACLs in an installer.
>
> Is it possible to modify ACLs during installation with VS.Net (2005)
> setup projects (merge module or msi)?
>
> Is it possible to modify ACLs during run-time execution of a GAC DLL
> assembly? e.g. is it possible to call some code which will result in
> the "do you want to allow this" dialog being pop'd up and if the user
> says "Accept", that then gives me administrator privileges to do
> whatever I want?
>
> For example, could someone give me a 3-5 sentence explanation why what
> I said earlier didn't work?
>
> +-------------
> I even tried to use:
> RegistryPermission rp = new
> RegistryPermission(RegistryPermissionAccess.Create , strRegKey);
> rp.Assert();
>
> in the GAC assembly to fake the system out that it has permission and
> not check the apps higher up the stack, but it just throws a Security
> Exception error.
>
> Is this because DLLs (even in the GAC) can't use SecurityPermissions?
>
> +-------------
>
> I appologize if these are basic questions, but I've looked at security
> for several days now and it isn't becoming clearer.
>
> Bob
>
> "Kerry Brown" <*a*m> wrote in message
> news:u$...
>
>> "Dominick Baier" <dbaier@pleasepleasenospam_leastprivilege.com> wrote
>> in message news: m...
>>
>>> I would say that changing the ACL on a common directory is no
>>> "workaround" - but the right way of doing it. That's what ACLs are
>>> for - either set the ACL to a group of users or use "authenticated
>>> users".
>>>
>> I agree. Vista uses the security mode of give out the least possible
>> amount of permissions for security. If you need different access to a
>> folder that you created in the appropriate location for shared data
>> then change the ACLs (for that folder and subfolders only) during the
>> program installation.
>>
>> --
>> Kerry Brown
>> Microsoft MVP - Shell/User
>> http://www.vistahelp.ca

I used "Directory.GetAccessControl", added my new ACL rule (i.e.
AddAccessRule) and then "SetAccessControl", and I'm sure you already know
what happened:

"Attempt to perform an unauthorized operation."

If I didn't have permission to write the file, I probably don't have
permission to change the permissions to write the file.

Is it possible to call some code which will result in the "do you want to
allow this" dialog being pop'd up and if the user says "Accept", that then
gives me administrator privileges to do whatever I want?

Thanks,
Bob


"Dominick Baier" <dbaier@pleasepleasenospam_leastprivilege.com> wrote in
message news: m...
> Yes,
> you can write a custom action in the VS installation project - the APIs to
> change ACLs can be found in System.Security.AccessControl.
>
> e.g. Directory.GetAccessControl(..)
>
>
> -----
> Dominick Baier (http://www.leastprivilege.com)
>
> Developing More Secure Microsoft ASP.NET 2.0 Applications
> (http://www.microsoft.com/mspress/books/9989.asp)
>
>> My original concern is that in order to make this work, I didn't want
>> to have to tell the user, "Log in as administrator, go to
>> such-and-such folder, right-click and choose Properties, Security..."
>> and I don't personally know how to set ACLs in an installer.
>>
>> Is it possible to modify ACLs during installation with VS.Net (2005)
>> setup projects (merge module or msi)?
>>
>> Is it possible to modify ACLs during run-time execution of a GAC DLL
>> assembly? e.g. is it possible to call some code which will result in
>> the "do you want to allow this" dialog being pop'd up and if the user
>> says "Accept", that then gives me administrator privileges to do
>> whatever I want?
>>
>> For example, could someone give me a 3-5 sentence explanation why what
>> I said earlier didn't work?
>>
>> +-------------
>> I even tried to use:
>> RegistryPermission rp = new
>> RegistryPermission(RegistryPermissionAccess.Create , strRegKey);
>> rp.Assert();
>>
>> in the GAC assembly to fake the system out that it has permission and
>> not check the apps higher up the stack, but it just throws a Security
>> Exception error.
>>
>> Is this because DLLs (even in the GAC) can't use SecurityPermissions?
>>
>> +-------------
>>
>> I appologize if these are basic questions, but I've looked at security
>> for several days now and it isn't becoming clearer.
>>
>> Bob