General discussion


A possible consequence of disabling UAC (User Account Control)

By wyndham ·
I have just discovered a possible reason for a problem that I (and many others) had been experiencing with Google installing it's Chrome browser into a user's data location instead of the standard 'Program Files' or 'Program Files (x86)'.

If this is true, and I haven't done any tests on this yet to verify, partial apologies to Google for all the negative comments as they have to work with Windows with all its foibles, but only partial because they didn't tell us.....

Apparently, as previously noted I haven't proven this yet, if you disable the awful UAC (User Account Control), then sometimes (it seems random somehow, although computers are not supposed to behave randomly), a user will not be treated as having Administrative privileges. One consequence of this is that, any installer program trying to create sub folders in 'Program Files' or 'Program Files (x86)', will be blocked and so the installer will just go to a location it knows it can use - hence installation into the user data files folder.

The way around this is to run the setup/install program with Admin privileges. Usually right-click on the executable file and choose the option.

1) User disables UAC - usually done after installation of Windows. Users may not be aware of this as many PC builders - possibly all - do this automatically when installing Windows for their customers.
2) Installer program (such as Google Chrome) is blocked from installing into the standard program files locations (ie can't create sub-folders)
3) Installer program installs into a location which grants privileges to install (create sub-folders) - they always seem to go for the user data folder (location)

NOTE This should only be a problem on 64 bit Windows.

I'd be interested in other people's experiences regarding this.

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Not sure where the smoking gun is...

by AnsuGisalas In reply to A possible consequence of ...

Without UAC, there is no way for a limited account to exert admin privileges.
That's how it's supposed to be, you don't want your users walking through your flower beds in oversized admin shoes, heck, you shouldn't want to do that yourself, either, when it's not necessary.
Without admin rights (or even the temporary elevation that the UAC can grant) the users can't install to system folders, which is also as it should be. You don't want to root their "useful browser TOOL-bars" out of there all the time, easier to just delete user files wholesale

Edited to add: If your "PC builder" disables part of your OS without telling you, fire their asses. Nothing should be done with a computer that isn't documented. I find it hard to believe that any serious PC supplier (i.e. not one's "wiz-kid" nephew) disables UAC by default. It may be that some set up a default account with admin rights, leaving it up to users or their overseers to set up a limited account for every-day computer use.

Collapse -

I've seen better implementations of UAc is meant to do

by Tony Hopkinson In reply to A possible consequence of ...

but it's way better than nothing....

Collapse -


by AnsuGisalas In reply to I've seen better implemen ...

Better than having users using admin rights for pr0nsurfing, that's for sure.

Collapse -

Google Chrome browser install blows

by Neon Samurai In reply to A possible consequence of ...

I'm with you on how Google chose to implement it's installer. No user should be able to install software even if it remains within there profile. They can always use a portableapp version if really that essential and at least it can be cleanly uninstalled by deleting the directory. Chrome's installing binaries into the user profile is a mess. I don't want one install per user on a shared machine nor do I want a shoddy install that doesn't provide a centralized installer that doesn't clean up after itself. This has actually disqualified it for use in our environment because Google chose to design it to get around security.

In terms of UAC though, I have to disagree. The lack of any attempt at real privileged separation in Windows has been a long standing designed vulnerability. I know MS intentionally implemented it to harass consumers but they did improve the implementation for Win7 due to public response to Vista and it's UAC. In the last six months, I've probably been full Admin on my Win7 work machine five or six times. The rest of the time I'm in as regular User and using UAC/Runas only as required. I actually wish the userland developers would take more advantage of functions availabe in the Win7 OS kernel; rumour is that it's actually very solid in terms of privaledge management but the userland devs ignored or skimped on implementing them. By contrast, Apple has done a very nice implementation in osX with it's simply "click the lock to change settings as Admin" as have various Linux distributions that simply ask for the relevant password when attempting to do an Admin function.

Regardless of the implementation, the "sudo" concept is an important part of providing proper privileged separation. A full Admin login should be extremely rare beyond initial install, privileged separation should be strong from kernel to most superficial levels, a mechanism should be provided to allow authorized users to run the minimum they need to do with temporary Admin permissions.

Collapse -

Did you know?

by wyndham In reply to A possible consequence of ...

The responses have been interesting and illustrate that perhaps I hadn't been clear.

Maybe I should have titled the discussion 'Did you know that users with admin rights do not always have those rights?'

The point I tried to make, apparently not very well, was that I, as a user with admin rights, did not realise that a program I was running was doing so without admin permissions.

I was not advocating that users should disable UAC, even though I did indicate I dislike it. That does not mean I don't appreciate the idea. What I didn't understand were all of the consequenes of disabling.

Apologies for any typos, etc as I am writing this on my phone :)

Collapse -

Thanks for clearing that up.

by AnsuGisalas In reply to Did you know?

I agree that Microsoft can still learn something about documenting what the things they program do, or don't do. Diplomatically speaking.

Collapse -

UAC Causes Random errors on some installers

by rj In reply to Thanks for clearing that ...

I am the software engineer for a company that just released a new application and the first thing we ran into (even after extensive testing) was user reports of the software not installing properly. I tracked it down to not allowing proper permissions upon installation, missing registry entries, missing icons, uninstaller won't work...yet it installs the application. This has been a nightmare for me the past few days...

I now have to update our installer software and script a brute force admin install for all Windows systems to hopefully prevent this. It certainly made us look bad and it was not even anything under our control...

wanted to make clear, this happens randomly...we have yet to find any one, single solitary reason this happens...

Collapse -

Yes I did

by Tony Hopkinson In reply to A possible consequence of ...

Got to agree, it's far from clear that UAC off != no UAC, but having been working on a complex installer, I ran into this more than a few times..
If you want some real fun, Virtualisation a la Vista, and XP's Run as Admin fetch in some fun and interesting wrinkles as well.

The thing to remember is when you elevate through UAC you get another security context, you are not you, you are you with a set of permissions authorised by UAC. Whether you thought you already had those permissions because you are local admin is irrelevant.

Related Discussions

Related Forums