Prev: Listview trouble
Next: MFC and OpenGL in VS9
From: Dee Earley on 26 Feb 2010 09:51
On 26/02/2010 13:13, Bob Masta wrote:
> On Thu, 25 Feb 2010 16:44:34 +0000, Dee Earley
> <dee.earley(a)icode.co.uk> wrote:
>> On 25/02/2010 14:23, Bob Masta wrote:
>>> On Thu, 25 Feb 2010 09:54:53 +0000, Dee Earley
>>> <dee.earley(a)icode.co.uk> wrote:
>>>> You can not reliably write into one users profile when running as
>>>> another user (Windows security is specifically designed this way)
>>>> Even if you could, it would only exist for one user and all others would
>>>> find it missing.
>>>
>>> Agreed, which is why it is so mystifying that
>>> Microsoft would have changed from simple elevation
>>> in XP to actual account switch in Vista/7. After
>>> all, the Standard User account has just entered an
>>> Admin password to be able to install the app...
>>> why, oh why would Microsoft want to grant him the
>>> ability to mess with the Admin's private folders?
>>
>> Erm, XP didn't have elevation of any form, it ran as an admin user (if
>> required)
>> Vista and Windows 7 does exaclty the same for non admin users, the setup
>> will end up running AS the admin user.
>
> In XP, if a standard non-admin user runs the
> installer, it can install to Program Files, write
> the registry, etc. But it does not run AS the
> admin... it writes to the user's Documents, not
> the admin's. The user has admin privileges
> without assuming his identity.

I expect this was a power user which has the ability to write to these
locations.
You can do the same in Vista if you adjust the permissions.
Vista will do the same with your unelevated "admin user" (closest thing
to a power user)

>>> It seems that the new Vista/7 UAC approach is
>>> *less* secure, not more. What were they smoking
>>> in Redmond?
>>
>> How is it less secure?
>> You can't get admin access unless you enter admin detaisl and run as
>> said admin user.
>
> Think of this like valet parking. The valet
> (standard user) needs to be able to drive your
> car, but he doesn't need access to your trunk or
> glove compartment. You (admin) give him a "valet
> key" that works in the doors and ignition, but
> nothing else. He can get the job done, but not
> mess with your personal stuff.
>
> Under the Vista/7 scheme, you have to give the
> valet your whole key ring... home, safe deposit
> box, everything.

Unless you specifically make/ask for a valet key (change the permissions)

> The XP system only grants the needed access, not
> the whole identity. It's not only safer for the
> admin (whose folders might get changed
> inadvertently), it's better for the user since he
> can install properly to his own folders.

Yes, write access to the Program Files, which is as much a security risk
as full admin access.
They can update/overwrite executables that others users (even a real
admin) may run, potentially breaking the syetem or givign them the extra
access.
Think of this as giving the attendant the valet key but leaving your
full set of keys on the passenger seat.

>>>> If you want the user to have certain files in their profile, copy on
>>>> first run as that user, or provide two parts.
>>>> Inno will allow both situations, but not really in the same setup
>>>> (although one can be embedded in the other)
>>>
>>> Yeah, I am aware of the 2-part installer trick; a
>>> similar "fix" is available for NSIS. What a
>>> kludge!
>>>
>>> You'd think with all the Microsoft talk about how
>>> everyone should run at the lowest privilege level,
>>> they wouldn't make it so needlessly hard to do.
>>> (Grumble, grumble...) ;-(
>>
>> It's not hard, it is the default state of any user and their processes.
>> What you can't do is drop the privileges once you have them which is why
>> Inno first runs as the current user, then elevates a second copy of
>> itself to do the actual install.
>> Unfortunately, this unelevated part is limited to running executables.
>>
>> Windows Installer (MSI) does similar, but only elevates during the
>> actual install phase (as they have far more controlled access to code
>> and the data to be installed) so can still install (current) user
>> specific files.
>>
>> This is still a bad idea as if another user runs it, they won;t have the
>> user specific data and depending on usage, can fail.
>
> All that is needed is to allow elevation (access
> to Program Files and registry) without identity
> change.

But a "standard" user has nothing to elevate to.
The split token and elevation only applies to "admin" users anyway.
When runnign under the reduced users security context, it has NO WAY of
accessing anything that that user won;t normally have access to.

> This really only comes down to which
> shell path is used for certain folders. Vista/7
> "knows" the identity of the original user, because
> it does write to the user's Start Menu and Desktop
> properly. (Although it does write to admin as
> well.)

Where does it?
Most applications I know of put icons in the shared start menu and
desktop which are merged so all users access it.
Try deleting one of these as a normal user and Windows will warn you
that it will effect everyone else.
Further more, non admin users won't be able to move or delete them.

> It just refuses to use the user identity
> for folders like Documents.

While there is a shared documents, it is not merged as the start menu
and desktop are.
Windows will normally put a shortcut in the Documents folder to the
shared location.

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

iCode Systems
First  |  Prev  | 
Pages: 1 2
Prev: Listview trouble
Next: MFC and OpenGL in VS9