Re: Vista/7 permissions for script?
- From: "Alex K. Angelopoulos" <alex(dot) k(dot again)angelopoulos(at)gmail.com>
- Date: Mon, 18 May 2009 17:15:23 -0400
Yes, can be _horribly_ confusing - it was for me. In fact, I was really micturated about the behavior. ; )
The first problem is wrapping your head around what really happens with elevation, something that they don't talk about much. What it comes down to is when an administrative user logs on to Vista/Win7, they get two access tokens: their normal one with full privileges, and another one with admin privileges stripped off for normal use. See here for some more detailed explanation:
http://blogs.msdn.com/uap/archive/2005/10/13/480740.aspx
The fundamental concept for understanding what happens is to know that when a process starts, it inherits the standard access token unless you request the privileged one specifically. There's another layer to this; some applications (mmc and regedit, for example) contain manifests that mark them as requiring an elevated token, which forces prompting when they start up. That's why you get prompting automatically for REG files and MMC files, but don't if you try to open a log file in the Windows folder. Notepad doesn't think it needs special privileges to open that file, and consequently you won't be able to overwrite the original if you modify it.
"mayayana" <mayaXXyana@xxxxxxxxx> wrote in message news:ukgwq8x1JHA.6056@xxxxxxxxxxxxxxxxxxxxxxx
I have almost no experience with Vista but
recently started testing my software and
scripts on Win7 RC. I'm confused by the
permissions issues and wanted to ask how other
people are handling them. Examples of problems
even when running as an admin:
* I can write a set of "Open With X" Registry
keys under HKCR\* in Regedit, but can't do it
programmatically from software that admin is
running.
Because you automatically get the elevation prompt when running regedit, of course. Note that you _can_ still write to per-user registry keys, including the admin user's for per-user associations under HKCU\Software\Classes. If you want to write to the actual key itself from that HTA, you have only two choices: either start the HTA elevated or launch a separate elevated script. Either one has limitations, some of which you've encountered.
Elevating the HTA is reasonable, and in fact makes the most sense to me. You can't do that by default, of course, so you need custom registry extensions for special filetypes. I've seen a couple of those, and if I did more point-and-click work I'd already have written a generic implementation for every major script type on my system. Unfortunately, you don't get drag-and-drop support from the desktop to an HTA, for example.
The alternative is to dynamically generate the modifications and launch them in a script. This is painful from HTA (although there may be way to access ..NET and use the System.Diagnostics.Process class directly). With registry changes, there's a handy way to do this simply: autogenerate a REG file, then invoke it. Since Regedit always gets a prompt for elevation, it gets handled for you. This is clunky, but workable.
* I wrote an HTA for managing services via WMI
but access is denied when using the HTA to
change services. Admin can change settings
directly through the services applet, but not through
the HTA. And there's no "Run as Admin." on the
HTA context menu.
Again, you get prompting for elevation automatically when running MMC. The behavior for specific applications such as regedit and mmc.exe comes from their embedded manifests; they contain a requestedExecutionLevel element that asks for elevation. It would be possible to modify hosts such as mshta to do this automatically, but then normal users couldn't run them.
* 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.
I was thinking that it might be worthwhile to write
an ActiveX DLL for file operations and Registry edits
that conveniently incorporates the ability to set
permissions in order to allow a given operation -- in
other words, render permissions altogether "transparent".
That could be convenient for scripting, but if the DLL
does not have permission to do its work when run from
a script then it's not of much value. Is there any way
around this mess without needing to resort to command
line or specifically selecting to run a given process as
admin.? (I didn't think to check whether VBS files have
a "Run as Admin." context menu, but even if they do that's
not an adequate solution.) Is script in Vista/7 doomed to
be limited to what admin. can do without getting a UAC
prompt?
Assuming "runas" were a viable menu choice for vbs/wsf/js/hta/cmd files, what are the inadequacies you see?
The primary issues I was able to recognize come down to two specific irritations.
(1) I can't elevate at-will. For example, I've done test runs on scripts from within my text editor for years. I can't do that now with full privileges; I need to either run the editor elevated, or launch it externally
(2) No drag/drop: if you start a graphical application with a full access token, you can't drag items from the restricted shell into it.
Resorting to the commandline doesn't really provide you with anything special, by the way. You just get an apparent boost by the fact that you can request elevation launching shells other than explorer.exe, and thus already have a privileged token. This is definitely an issue in my opinion, and the correct way to resolve it is to extend document types to allow a request for elevation from specific documents. Another way around it (which I haven't yet explored) is to use a custom launchpad or file manager that is itself launched with a request for elevation.
This is not even getting into how to manage if I
were to run as a normal "user". I'm just trying to
figure out how to have full permission to use a
Vista/7 when I'm admin.!
Yes. This is where I ran into a brick wall until I got the process launch elevation issue.
A similar problem has been designed into some
Linux systems, whereby root is not really root and
needs to give itself "superuser" rights. But once one
is SU there are no limitations. On Vista/7 I was under
the impression that running this command line was
equivalent:
Net user administrator activate:yes
But as far as I can see, that still doesn't give me
the full control that I have naturally on Win9x or
as admin on WinXP.
I wasn't even aware of the net user hack. Frankly, the real security issue was never resolved on UNIX - which is how do you provide a full graphical environment with safe but transparent elevation where you need it?
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. The reason I say that is I've run into dozens of small applications that fail in odd ways under UAC, and most do so because they make an assumption about the developer having the right to make any changes he wants to a machine. This is a nasty habit, and UAC forces developers to fix the problems. It does introduce pain, I can tell you from experience, but it actually works out ok once you have a chance to get oriented.
.
- Follow-Ups:
- Re: Vista/7 permissions for script?
- From: mayayana
- Re: Vista/7 permissions for script?
- References:
- Vista/7 permissions for script?
- From: mayayana
- Vista/7 permissions for script?
- Prev by Date: Change share script
- Next by Date: Re: Change share script
- Previous by thread: Re: Vista/7 permissions for script?
- Next by thread: Re: Vista/7 permissions for script?
- Index(es):
Relevant Pages
|
