On Tue, 16 Feb 2010 20:41:22 +0100
Christian Franke <Christian.Franke@...> wrote:
> Smartctl provides also limited functionality (-c, -i without serno, -A
> without thresholds) for normal users through two I/O controls which do
> not require admin rights.
Yes, I have that problem with GSmartControl too (it does provide some
non-admin functionality, albeit very limited).
> Running with elevated privileges through UAC unfortunately does not work
> like e.g. running a setuid program would work.
> At least on Vista, a "requireAdministrator" level in a smartctl manifest
> effectivly prevents interactive use from both normal and admin user's
> console. After the UAC confirmation prompt, smartctl is started within a
> new console with new cwd, new environment and stdio not inherited. Then
> smartctl output is invisible and cannot be redirected.
> It only works if console is itself started with full admin rights.
> Without a manifest, it works in all cases on Vista.
Seems to be the case under win7 too (I just tested it). I should have tested
this before writing the original e-mail, sorry. :)
> > Windows 7 changed the default behaviour of "unmanifested"
> > executables. Vista would just run them in compatibility mode,
> > effectively giving them administrative rights. Windows 7, on
> > the other hand, runs them in "user" mode (even if the logged
> > in user is the administrator), denying them access to system
> > resources.
> Is this also true if smartctl is run from cmd.exe (or gsmartcontrol.exe)
> which is explicitly started with full admin rights?
> In this case it may help to add a manifest which requests the default
> "asInvoker" level to prevent this behaviour.
It seems that when running from an admin-launched program
(gsmartcontrol with admin rights, or cmd), smartctl inherits its
permissions, so no problem there. Additional manifest doesn't
seem to be required (or used, in terms of UAC).
> Unfortunately I don't have a Win 7 for testing.
> For testing on Vista, I also successfully used external manifest files,
> see attachment. This may also work on Win 7 if the .exe itself doesn't
> contain a manifest. If this is the case, external manifests may be a
> more flexible alternative.
MS documentation was really unclear about those, and it appeared
that they didn't work when I tested them.
Now that I tested them again, turns out Windows caches
them in a way that the edits (and even creating / removing them)
don't get picked up by the system unless you rename the whole
directory or reboot a computer. So I kind of missed the whole feature
when I wrote the first e-mail.
To summarize the problems of the smartmontools distribution when
running under win7, they are:
* The drive right-click commands don't work (permission denied).
* The items in start menu don't work (permission denied).
An external manifest (with admin requirements) should fix all that.
But it introduces these problems:
* Vista users won't be able to run it in non-admin cmd window (not sure about this).
* Regular users won't be able to use non-admin functionality.
Having two exe files (one with manifest, one not) is probably an overkill, I guess.
Maybe some kind of a wrapper (like runas command) should be used?