This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 232535 - Installer needs admin rights on Win7 64bit but on WinXP 32 it doesn't
Summary: Installer needs admin rights on Win7 64bit but on WinXP 32 it doesn't
Status: REOPENED
Alias: None
Product: installer
Classification: Unclassified
Component: NBI (show other bugs)
Version: 7.4
Hardware: PC Windows 7
: P3 normal with 1 vote (vote)
Assignee: Libor Fischmeistr
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-10 20:59 UTC by markiewb
Modified: 2019-02-08 05:13 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description markiewb 2013-07-10 20:59:57 UTC
ACTUAL:
Installer requires admin rights using Win7 64bit.
Installer doesn't requires admin rights using WinXP 32bit

EXPECTED: (BestCase:) Don't require admin rights at all OR 
Do not require admin rights for installation of NB, but ask for admin rights from within the installer when you need them (for example: installation of bundled JDK/Glassfish)
Comment 1 Jiri Rechtacek 2013-07-11 06:36:28 UTC
Win 7 requires Admin privilege to allow the installer write in C:\Program Files, Win XP doesn't require this privilege I guess.
Comment 2 Libor Fischmeistr 2013-07-11 07:04:03 UTC
(In reply to comment #1)
> Win 7 requires Admin privilege to allow the installer write in C:\Program
> Files, Win XP doesn't require this privilege I guess.

That's right. On the user rights on XP and 7(or Vista and newer) differs. If you don't have rights to write to Program Files on Win 7 the installer wouldn't let you to do it. You can choose some writable destination.

I don't consider this as issue.
Comment 3 markiewb 2013-07-12 23:01:25 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > Win 7 requires Admin privilege to allow the installer write in C:\Program
> > Files, Win XP doesn't require this privilege I guess.
> 
> That's right. On the user rights on XP and 7(or Vista and newer) differs. If
> you don't have rights to write to Program Files on Win 7 the installer wouldn't
> let you to do it. You can choose some writable destination.
> 
> I don't consider this as issue.
Why does NB needs to write to "Program Files"? I always install NB to a different folder where I am the owner of. So in my case there is no need for using root privileges. Is this valid or did I miss something?
Comment 4 Libor Fischmeistr 2013-07-15 08:31:23 UTC
(In reply to comment #3)
> Why does NB needs to write to "Program Files"? I always install NB to a
> different folder where I am the owner of. So in my case there is no need for
> using root privileges. Is this valid or did I miss something?

To fully clarify the problem of rights I have to say, that the writing to the Program Files is only the one half. The installer also have to write to system registries and it needs admin rights too.

So, you want to install application to some destination you have the write access to, but the installer have to create some records to Windows registry and it cannot be done without admin rights.

That's why the installer requires admin rights. And it's the way how should it work and how it is setup on Windows.

If you want to use NetBeans on your computer without admin rights, use OS independent zip archive.
Comment 5 phansson 2015-07-01 14:24:57 UTC
Just for the record I'm not sure what is stated here is true.

Some things that to the best of my knowledge requires Admin Privs on Windows:

1. Writing to "Program Files" or "Program Files (X86)".  (we could more elegantly phrase this as either the %ProgramFiles% or the %ProgramFiles(x86)% location)
2. Installing shortcut in Start Menu for *all* users.

Sure, these things require Admin privs.

However when it comes to Registry Keys I'm not sure you are right that they necessarily require admin rights.

NBI puts stuff into HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall so that the application shows up in Control Panel --> Programs and Features. For 32-bit applications installed on a 64-bit OS this path would be instead : HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall.

Now, if a user doesn't have admin rights he can actually create the exact keys in Registry, except it is in HKEY_CURRENT_USER.

What the user sees in Control Panel is actually the amalgamation of information from 4 (four) different locations in Registry:   32-bit location and 64-bit location, HKEY_LOCAL_MACHINE hive and HKEY_CURRENT_USER hive.

So, in conclusion, and as far as my knowledge goes, there actually nothing to prevent having a true installer on Windows that will work even for users without admin privs. Furthermore, from what I can tell from WindowsNativeUtils.java (part of NBI engine) the distinction between HKCU and HKLM is actually fully present in NBI. So, it *SHOULD* work.

The only thing I can think of is that there's a request of Admin Privs added to the installer through the Windows Manifest, i.e. the installer requests such privs but doesn't truly need it.
Comment 6 mann 2016-03-31 09:08:04 UTC
This applies also to the applications created based on the Platform. This can seriously hinder end users and there should be an option of installing w/o admin rights unless strictly needed.
Comment 7 mrl 2019-02-08 05:13:59 UTC
I'd like to say the idea that it requires admin rights to install is ridiculous. It's extremely contrary to one of the strongest attributes of Java, where its ubiquity of being able to "run anywhere" is limited by file or "registry" permissions.  It rights to the "registry" ?!? If this is the case, again a horrible design decision.  The power of Java is the capability of running anywhere, yet this IDE has managed to incorporate dependencies that prevents it from running in fairly common use cases.

Get rid of the "Windows specific registry writes"
Get rid of the "Windows program files write requirements"
Get rid of the Administrative privileges requirements.