Open Bug 841777 Opened 7 years ago Updated 5 years ago

Mozinstall requires highest privilege

Categories

(Testing :: Mozbase, defect)

All
Windows 8
defect
Not set

Tracking

(Not tracked)

People

(Reporter: armenzg, Unassigned)

References

Details

Attachments

(5 files)

It happens that having "install" in the name causes UAC to prompt regardless if the script is already running as Admin (IIUC).

I could change the console scripts to name it something else but I'm open to try other alternatives.
Blocks: 840926
Is the platform as specified accurate?  I thought this was a windows issue.

I had forgotten about this "security" "feature" wrt mozinstall.  We should probably rename the console script to, say, moz-add-to-system or some such nonsense.  I'd also be down for having an alias (that is, have two console_scripts pointing to the same thing).
Armen, have I ever told you you're my hero?
Ted pointed out they worked around this problem in the past with a manifest: http://mxr.mozilla.org/mozilla1.9.2/source/config/nsinstall.exe.manifest

See "installer detection": http://msdn.microsoft.com/en-us/library/aa905330.aspx#wvduac_topic3

Also a slightly confusing blog post: http://higery.wordpress.com/2011/07/12/automatic-script-creation-the-entry_points-on-windows/

I'd vote for the manifest approach, but if it turns not to work we can always do the alias thing that jhammel suggested.
OS: Mac OS X → Windows 8
Hardware: x86 → All
I'd tend to avoid the manifest approach since, IMHO, it is yet-another-thing-that-could-go-wrong-and-require-debugging.  That said, I don't really care as long as it gets fixed.
This does the job for me.

I will look at the manifest.
FWIW, manifests are the documented and supported way to avoid the UAC headache on Windows. I don't know how much of a pain it is to make setuptools use them.
Duplicate of this bug: 841818
I have tried doing this.
The only progress I made is to include a mozinstall.exe.manifest (by adding it to MANIFEST.in) to the egg but it does not get installed.

I won't be able to touch this again until Tuesday/Wednesday.

If someone with more Python packaging skills could pick it up that would be great.
just a general idea to avoid UAC etc, would it be possible to call python mozinstall-script.py instead of the .exe at least this workaround UAC
hm so it didn't worked for me - tried with different manifest file contents and the mt tool and always into the UAC prompt 

my manifest file


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
            <requestedPrivileges>
                <requestedExecutionLevel level="asInvoker" uiAccess="false"/>
            </requestedPrivileges>
        </security>
    </trustInfo>
</assembly>    

and the command to bring into mozinstall was

C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin>mt.exe -nologo -manifest "C:\U
sers\mozilla\Documents\mozinstall.exe.manifest" -outputresource:"C:\Users\mozill
a\Documents\mozinstall.exe;#1"

anything i did wrong here.

With spending all this time on the mozinstall issue i really wonder if renaming would not the better way
> With spending all this time on the mozinstall issue i really wonder if renaming would not the better way

FWIW, I'm +1 for this for this reason.  Just the console_script, not the whole package, unless you want to sink time into that.  What an idiotic "security" "feature", though I must admire microsoft's ability to waste their competitors' time so effectively.
With the following patch I have managed to generate a package that includes the manifest but the problem is that it goes to the wrong place.

It goes to here:
C:\slave\test\build\venv\Lib\site-packages\mozinstall\mozinstall.exe.manifest
instead of here:
C:\slave\test\build\venv\Scripts\mozinstall.exe.manifest

Even if I copy side by side the exe file it does not do what we would expect it to do.
This article
http://msdn.microsoft.com/en-us/library/windows/desktop/bb756929.aspx
says that something like this is needed:
mt.exe -manifest "$(ProjectDir)$(TargetName).exe.manifest" -updateresource:"$(TargetDir)$(TargetName).exe;#1"

(which is what Tomcat tried)

Unfortunately we don't have mt.exe on the test slaves.
+1 with changing the console script name (but not the package). Maybe: mozsetup, mozdeploy, mozinitiate...
(In reply to Andrew Halberstadt [:ahal] from comment #17)
> +1 with changing the console script name (but not the package). Maybe:
> mozsetup, mozdeploy, mozinitiate...

I like mozdeploy the best of these, as un-semantic as it is.  TBH, I would use moz-add-to-system to make it glaring what is going on, and either way i think we should add to the docs a sentence about why the executable is not this (or if we alias the console_script, why there are two).
Anyone want to take the review?

This generates both set of executables (including "install" in their names and not).

It uses the "moz_add_to_system" and "moz_remove_from_system".


We should need mozharness patches desktop unit tests on Linux and Mac to use mozinstall instead.
Attachment #716214 - Flags: review?
We can work around the mozinstall.exe issue by calling mozinstall-script.py directly.
Attachment #716214 - Flags: review?
No longer blocks: 840926
(In reply to Armen Zambrano G. [:armenzg] from comment #19)
> Created attachment 716214 [details] [diff] [review]
> create 2 more exe files that do not have "install" on their name
> 
> Anyone want to take the review?
> 
> This generates both set of executables (including "install" in their names
> and not).
> 
> It uses the "moz_add_to_system" and "moz_remove_from_system".
> 
> 
> We should need mozharness patches desktop unit tests on Linux and Mac to use
> mozinstall instead.

FWIW, I'm +1 on taking this anyway even though you cleared the review flag.  Regardless of how we work around it for e.g. this production issue, the problem remains.  :ahal, :wlach, what do you think?
Flags: needinfo?(wlachance)
We worked around it by calling directly the python script.
That is why I removed the flag and the blocking dependency.
(In reply to Armen Zambrano G. [:armenzg] from comment #22)
> We worked around it by calling directly the python script.
> That is why I removed the flag and the blocking dependency.

Again, yes for the use case of mozharness, yes.  If this is the scope of the bug, then I can file another bug (or someone else can, ha) for the general case but I infer from the component = mozbase and title that this is the general bug.  That is, us working around it by calling the python script != fixing the problem for everyone.
I'm fine with the proposed solution. Whatever works. (tm)
Flags: needinfo?(wlachance)
Comment on attachment 716214 [details] [diff] [review]
create 2 more exe files that do not have "install" on their name

Going to go ahead and take this.  Docs should be written, yada yada, but in any case I'd rather fix this and move along than not.
Attachment #716214 - Flags: review+
(In reply to Jeff Hammel [:jhammel] from comment #25)
> Comment on attachment 716214 [details] [diff] [review]
> create 2 more exe files that do not have "install" on their name
> 
> Going to go ahead and take this.  Docs should be written, yada yada, but in
> any case I'd rather fix this and move along than not.

pushed: https://github.com/mozilla/mozbase/commit/8368095823fe55a884672ef21d5a638694b1879a

Will do the version bump and pypi release manually for this one as a follow-up
(In reply to Jeff Hammel [:jhammel] from comment #26)
> (In reply to Jeff Hammel [:jhammel] from comment #25)
> > Comment on attachment 716214 [details] [diff] [review]
> > create 2 more exe files that do not have "install" on their name
> > 
> > Going to go ahead and take this.  Docs should be written, yada yada, but in
> > any case I'd rather fix this and move along than not.
> 
> pushed:
> https://github.com/mozilla/mozbase/commit/
> 8368095823fe55a884672ef21d5a638694b1879a
> 
> Will do the version bump and pypi release manually for this one as a
> follow-up

Tagged.  I lost my pypi credentials so I cannot upload there for the time being.
Putting the tarball of 1.5 here so that it won't be lost.  If anyone else feels like uploading, please do so.
(In reply to Jonathan Griffin (:jgriffin) from comment #29)
> Pushed to pypi:  https://pypi.python.org/pypi/mozInstall/1.5

Thank you very much, Jonathan :)
FTR another mozinstall bug is being fixed in bug 1155743 to prevent hitting the UAC prompt.
You need to log in before you can comment on or make changes to this bug.