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)

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" <pete_dembrowski (AT) hotmail (DOT) com> wrote

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" <rv (AT) invalid (DOT) org> wrote

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)

folder>>

"Dominick Baier" <dbaier (AT) pleasepleasenospam_leastprivilege (DOT) com> wrote in
message news:51eb3048bb418c936806ca19560 (AT) news (DOT) microsoft.com...

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" <kerry (AT) kdbNOSPAMsys-tems (DOT) c*a*m> wrote

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" <pete_dembrowski (AT) hotmail (DOT) com> wrote

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)

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 (AT) pleasepleasenospam_leastprivilege (DOT) com> wrote in
message news:51eb3048bc5c8c93741d9bf4c20 (AT) news (DOT) microsoft.com...