The pkg(5)-based add-on and update tools used to manage updates and add-ons to
GlassFish v3 will not work properly when the GlassFish v3 installation is owned
by root and a user other than root attempts to use that tooling.
The following issue affects NetBeans download bundles that include GlassFish v3 Prelude and later on Mac OS X. The issue may have first occurred in the NetBeans 6.5 install bundles.
For example, in the NetBeans 6.8 RC1 Ruby bundle for Mac OS X, the included GlassFish v3's installation is owned by root and it's typically the case that the person performing ongoing update and add-on management of GlassFish v3 is not the root user.
Add-ons installed via the web admin console of v3 are likely not affected by
* Running bin/updatetool from a non-root account will result in a dialog stating
that permissions of several files differ from what is expected. (There's a related bug here concerning incorrect permissions of files in the glassfishv3/ area of the bundle that will be filed separately). Running updatetool as non-root makes the underlying permission setting issue come to light.
* Running bin/pkg from a non-root account results in a stack trace including the
same unexpected permissions error as seen when running the Update Tool GUI.
End User Workarounds
* Preferred: Perform a chown -R to set the ownership of the GlassFish
installation to the user that will typically manage that installation. For example:
sudo chown -R ckamps:admin /Applications/NetBeans/glassfish-v3-b73
Where in this example "ckamps" is the developer's user ID.
This workaround is a one-time step after which the user can directly execute the
bin/updatetool and bin/pkg tools directly. It also enables the background
notifier to periodically inspect the installation for updates and, when updates
are available, enables the Software Update GUI to operate properly.
* A partial workaround is to use "sudo bin/updatetool" and "sudo bin/pkg" with
the existing ownership in place. The shortcoming of this approach is that the
background notifier which is automatically started as a desktop login task and
any execution of the Software Update GUI will not work properly.
* Modify the bundle installer to force the GlassFish v3 installation to be owned
by the user running the installation program.
* Alternatively, it may be feasible to avoid requiring the entire installation
of the bundle to be owned as root and to simply have the installation owned by
the installing user.
Not feasible workarounds:
Simply playing with group permissions is not a feasible workaround or even
solution to the problem because the underlying pkg(5) system attempts to apply
file permissions to installed content as packages are updated. Thus, any
permissions changes specified by package maintainers may result in the pkg(5)
system issuing "chmod" to modify file permissions. When the non-owning user
effects such attempts, the pkg(5) execute chmod operations will fail.
Longer Term Solution
The Update Center project team that ports pkg(5) for use across a variety of OS
platforms and develops the associated GUIs and desktop notifier mentioned above,
are looking into how elevated privileges can be achieved on various platforms.
As mentioned earlier, this capability was implemented in support for Windows
Vista. Support on other platforms is under investigation.
Generally, based on how the pkg(5) system manages file permissions (see above),
shared group-based management solution is not feasible. i.e. simply aligning the
owning group ID with the group of a user along with proper group level file
permission settings is not a long term solution.
Might be Limited to Mac OS X
Practically speaking, this issue might be limited to Mac OS if the bundle
installers on Linux and XP default to installing into the user's home directory
or equivalent with the ownership of the installing user. On Vista, the issue
might not be present because the update tooling's .exe files are configured to
seek elevated privileges via Vista's UAC facility by default. (The same mixed
scenario has not yet been tested on Windows 7).
Similar Issue With GlassFish v3 + Eclipse Bundle
See similar situation with the Sun-managed Eclipse + GlassFish v3 bundle:
The code-based workaround used in that case was to include a post install script to change ownership of the GlassFish v3 portion of the bundle to the installing user ID.
The user experience of this issue is as follows:
1) Under Services, right-click GlassFish v3 Domain and select View Update Center.
2) The first time this selection is made, a dialog prompts whether the user wants to install the update tool. Clicking Yes will kick off the Java Boostrap. After a few minutes, the bootstrap installer will complete and the Update Tool GUI will be started.
3) As soon as the user clicks on Available Updates, Available Add-ons and Installed Components, an error similar to the attached file appears.
In the background, the desktop notifier that was registered by the Java bootstrap and is running under the user's ID will be unable to monitor the image for updates due to the mixed owner and user ID issue.
At this stage, the user will need to apply the "chown" workaround as described earlier in this report.
Created attachment 92236 [details]
Incorrect permissions error from Update Tool GUI
Another workaround for this issue is to use the Update Tool from the Admin GUI Console.
Using the web admin console does not provide a complete workaround because users cannot apply updates from the web admin console. The ability to update from the web admin console was disabled because of issues and/or concerns about attempting to update the running GlassFish environment.
Additionally, using the web admin console does not address the fact that the desktop notifier will not be able to poll and notify the users of available updates.
Given the inability to apply updates through the web admin console and our interest in ensuring that the desktop notifier is running properly, the recommended workaround should continue to be the use of the chown approach.
There is a workaround for end user to update GF using "sudo ..." commands which will be documented in Release notes of 6.8. The bug will be fixed in a next release of NetBeans. Likely in patch release of 6.8.
Note that the only viable workaround is to perform the sudo chown as documented earlier. For various reasons, using sudo to execute the Update Tool GUI in bin/updatetool, will not provide the desired results.
Integrated into 'main-golden', will be available in build *200912161400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Yulia Novozhilova <email@example.com>
Log: #177872: GlassFish v3 update tooling issue with root install
Overall, the results of the code-based workaround look good. Read further for more information and several additional observations with may or may not be issues.
Here are the results of running several informal tests of the development bundle:
1) I was able to successfully launch the Update Tool GUI from within NetBeans, browse Available Add-ons and install a selected Add-on.
2) In a second new install, I went straight to the CLI and was able to successfully execute:
$ bin/pkg list (which triggered the installation of pkg)
$ bin/pkg list
$ bin/pkg list -a
$ bin/pkg install ant
$ bin/pkg install updatetool
Several additional observations and comments:
1) It appears that most of the NetBeans IDE install is now owned by the user running the installer. I believe this is a useful change in the Mac OS X case. However, it's not clear to me why the installer still prompts for Administrative username/password. Perhaps the prompt is related to the next observation.
2) An attempt to rm -rf of the NetBeans .app directory failed due to the following files being owned by root:
/Applications/NetBeans/NetBeans Dev 200912161400.app/Contents/Resources/NetBeans/nb6.8
vpn-129-150-33-71:nb6.8 ckamps$ ls -al
drwxrwxr-x 3 ckamps admin 102 Dec 16 18:08 .
drwxrwxr-x 3 ckamps admin 102 Dec 16 18:08 ..
drwxr-xr-x 3 root admin 102 Dec 16 17:54 servicetag
Interestingly, I was still able to use Finder to move the .app area to the Trash.
> However, it's not clear to me why the installer still prompts for
> Administrative username/password.
- The problem is in previous installations. They were under root:admin, so to be able to rewrite files, installer needs Administrative username/password.
> An attempt to rm -rf of the NetBeans .app directory failed due to the
> following files being owned by root:
> $ pwd
> /Applications/NetBeans/NetBeans Dev
> vpn-129-150-33-71:nb6.8 ckamps$ ls -al
> total 0
> drwxrwxr-x 3 ckamps admin 102 Dec 16 18:08 .
> drwxrwxr-x 3 ckamps admin 102 Dec 16 18:08 ..
> drwxr-xr-x 3 root admin 102 Dec 16 17:54 servicetag
- Will be fixed soon. Thanks for catching.
Integrated into 'main-golden', will be available in build *200912230201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Yulia Novozhilova <firstname.lastname@example.org>
Log: #177872 GlassFish v3 update tooling issue with root install (second part)