Re: Vista/7 permissions for script?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



"mayayana" <mayaXXyana@xxxxxxxxx> wrote in message news:uS$jbXB2JHA.1196@xxxxxxxxxxxxxxxxxxxxxxx

Thank you, Alex. That's a lot of info. I was vaguely
familiar with UAC and elevation. Though I'm not
entirely clear about the result of turning off UAC.
I gather that I can choose not to receive the permission
prompts but in doing so I'm just giving up my chance
to have permission, not giving myself permission.
So I need to leave UAC enabled if I want to ever
be offered the chance to elevate?

Precisely. If you turn off UAC, you have essentially the same behavior as you do in XP/2000/2003, where if your account has administrative privileges, applications can make system modifications without you being aware of it. With UAC on, an application can only perform privileged operations if you run it with full privileges. The right name for the verb would be "RunPrivileged", since if you have a special account, you can elevate by responding to the prompt with just a "yes".


As far as I can
see, to talk about getting two "access tokens", and
the non-privileged one being the default, is just a
convoluted way of saying that admin. is not really
admin. Rather, it's a special status that might be
defined as "authorized to receive UAC elevation
prompts".

Actually, the definition of the _group_ Administrators would be "users who can elevate an application without providing credentials". Here's the behavior you get for the administrator account, accounts that are members of the administrators group, and normal users.

Administrator: If you log on as _the_ Administrator, everything runs with full privileges. You don't need to mess with anything, whether the application manifest says it wants elevation or not. You're always elevated.

Administrator group members: if you launch an application so that it asks for privileges - either because of the manifest or because you launched it with a UAC shield request - you get a UAC elevation prompt, and if you deny it, the process can't run.

Normal user: If you launch an application so that it asks for privileges, you get a UAC elevation prompt that's actually a logon dialog. If you supply credentials with sufficient authority, the process can then run.


Unless there's a specific method to dump
the alleged dummy "access token" and use the privileged
one alone -- a method that necessarily deals in terms
of "access tokens" -- then the whole concept seems to
be irrelevant and only adds to our collective confusion.

Could you explain what you mean by "dump"? I think I may understand what you're after, but to be clear about some background details, here's why I think it works this way after spending some time pondering the issue.

+ First of all, the core problem UAC is designed to solve is having applications do things to the system without you being aware of it. Malware was guilty of this, but there's an even wider range of "legitimate" applications that would do what they liked with special files or settings.
+ If there was a _programmatic_ way around this - some way for an application to silently get access to a token, it would be bad for obvious reasons; the same problems would occur all over again. So the UAC shield has to operate interactively.
+ Another option would be for an application to ask for privileges. This would require applications to be rewritten, and gets expensive in terms of processing power (in theory, anyway).

The solution they used was to do this:
(1) Since users may need to run an existing executable with special privileges, they added the RunAs option for executable files.
(2) Moving forward, applications can have an embedded manifest that requests special privileges at launch - the least expensive time to do it.

And there are oversights, of course. I can think of two:
(1) Application rather than document-centered configuration. A lot of the interactive tools people use are NOT executables. WSH scripts, HTAs, initialization files, and several others are also tools, but there's no obvious way to add simple RunAs functionality to the context menu unless you already know what's going on and know how to configure it.
(2) There's a catch-22 with some applications. For example, consider regedit on Win7. Running as THE administrator, there's no prompt; you can edit everything. That's to be expected. Running as a normal user, you get a request for elevation - and if you don't supply credentials, you can still open Regedit, but you can only do things to your own personal registry key. For a privileged user, however, if you deny the UAC elevation prompt, regedit won't run; if you accept it, you have unlimited access.

> * I've found that there are even some values in
> the Registry that Admin. seems to be completely
> denied access to.

That's always been that way, by the way.


In XP? I didn't know that. If I have to use XP I
generally prefer to use it installed on FAT32 so
that I don't have to deal with permission issues. So if
there are values I can't change in the XP Registry
then maybe I just haven't looked far enough. In
general I've found that XP is quite usable and
cooperative as a standalone system when installed
on FAT32, with PCHealth removed, and with most
services disabled. In that scenario I'm not aware
of any limitations.

There have always been a few keys where the administrator needs to have permissions in order to modify them. I may be remembering the cause incorrectly, though; some links in the registry give you access denied for other reasons having to do with the peculiar nature of the node. There's a similar issue with some system files starting with XP on NTFS; you don't have control over the System Volume Information folder; you need to take permissions if you want them.

If you mean always like Win9x always then I
think you must be mistaken. I've never run across
anything like that. I have, however, run across
hidden values on XP, where Regmon logged activity
in a key that Regedit wasn't showing to me.

The value in question in Win7 was nothing at
all "top secret". I was just moseying around, came
across a key for (I think) MessengerService. It
had a value with data that was something like
www.microsoft.com. Just a configuration value for
a service I'd never enable in the first place. Yet I'm
forbidden from changing/deleting that value. That
makes me think that much of the Registry must be
off-limits.


At this point, I have to say I personally find it to be annoying that it
doesn't work better for admins, but my overall reaction after nearly two
years of daily use is that UAC really is a good thing. .....It does
introduce
pain, I can tell you from experience, but it actually works out ok once
you
have a chance to get oriented.


No offence, but I'm not particularly interested in
the fact that you think UAC is a good thing overall.
Your experience is your experience. I'm on a stand-alone
PC, not in a corporate network. I'm the only user.
I don't want restrictions. In a corporation it makes
sense to lock all cabinets so that employees don't
steal. In a private office or home it's better to just
have a good lock on the front door. Different needs.

There IS something you can do to modify the behavior without disabling UAC on Windows 7. The next time you get an elevation prompt, click the "Change when these notifications occur" at lower right. You can drop the slider a couple of notches lower.

Alternatively, you can also add RunAs choices for other significant file types than just exe's. I'm in the process of writing a generic script to do that properly since another important issue coming up is that on 64-bit Windows, it's important to at least occasionally be able to specify either the 32-bit or 64-bit host for a script or HTA.

We could discuss that all day as a matter of opinion,
but at the end of the day it's my PC and I'm the one
who has to use it.

I don't think there's really a question about that; experiment with dropping the slider and see if it gives you what you want. Another option is to simply do what people always used to do (and what I did as well on XP): run as THE administrator account. It's not standard practice, and I think the arguments against doing so are solid, but enabling and using the built-in Administrator account does give you precisely the same experience as on any other Windows OS when running as the built-in Administrator. Including getting scripts and HTAs to run with full privileges without the UAC prompt.

I just want to know how to control
Vista/7 and eliminate restrictions. Maybe that's
not even possible. I want to find out for sure. If it's
really not possible then at least that will be worth
knowing before I go and waste any more time adapting
my scripts and software to Win7. The notion that I
might have to use an OS where Microsoft can access
the Registry and system folder, but I can't, is
simply not acceptable.

I haven't seen that yet, if it's any comfort. Could you try to find the registry key you can't touch? I would like to see if I have the same problem.

.

Relevant Pages

  • proposed changes to UAC mechanism, RunAs, and documentation
    ... The "Run as Administrator" option that appears when you right-click on a ... Vista's UAC implementation does not take into account or allow ... Accounts with the silent elevation ... If you are logged in as a Local Admin but not a Domain Admin you ...
    (microsoft.public.windows.vista.security)
  • Re: TAPI driver does not install on Windows Vista
    ... Vista will pop up the UAC dialog when the application ... dialog will appear on some operations that need elevation, ... Through a custom action calling the function directly ... There are two threads during a Windows Installer installation: ...
    (microsoft.public.win32.programmer.tapi)
  • Re: Undo Elevated Command Prompt
    ... The notion of elevating privilege is an aspect of the behaviour of UAC. ... With UAC OFF any command prompt run from an Administrator account (i.e. ... Administrator account) will always have Administrator rights, ... This is not "elevation", though, this is just ...
    (uk.comp.homebuilt)
  • Re: VBA FileCopy hangs with UAC
    ... with Administrator privileges; ... Administrator rights. ... I turned off UAC and had no problem manually copying the file from the ... No, the Access database file doesn't have Run as Administrator by default, ...
    (microsoft.public.windows.vista.security)
  • Re: UAC changes in Windows 7
    ... A more clever solution for securing the white-list would be to use a prompt (similar to UAC, trusted certificate installation, unsigned driver installation, running downloaded files) whenever a program is appended to this list that would alert the user only once and he/she could be free of unnecessary UAC prompts for the rest of his/her life. ... If the file is updated legitimately the installer would be able to update this hash as well but a malicious software using a security hole may not be able to do that. ... The change we made in Windows 7 default UAC settings is that any operation that is necessary to manage windows will not require an elevation - which in technical terms translates into a white list of trusted action / binaries which the user can make perform without UAC prompting from an elevation. ...
    (microsoft.public.win32.programmer.kernel)