Uploaded image for project: 'NetBeans'
  1. NetBeans
  2. NETBEANS-1800

Locked out of plugin installation due to netbeans requiring admin rights and wayland conflicting with running netbeans as root

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Blocker
    • Resolution: Information Provided
    • 9.0
    • 10.0
    • None
    • Antergos Linux 4.19.8-arch1, x86_64, Gnome/wayland (also affects all other known linux distros on gnome/wayland)

    Description

      On any linux distro running gnome/wayland, the typical tools to run a visual application as root (eg gksu, gksudo) do not work. Netbeans 9 requires installation of some plugins to be run as administrator (eg the JIRA plugin to interface with this board). There is no possible way to make this work on such systems. Using `sudo -H netbeans` and `sudo -E -H netbeans` will run the program, but then netbeans does not detect the original user or already configured settings. Reinstalling plugins from here does not propogate back to the standard user runtime.

      None of the following work due to various errors:

      • `sudo netbeans` - program fails with an exception
      • `gksu netbeans` - wayland prevents entering password, cannot proceed
      • `gksudo netbeans` - wayland prevents entering password, cannot proceed
      • `sudo -H netbeans` runs, but does not detect existing configuration, and breaks user runtime if reconfigured
      • `sudo -E -H netbeans` also runs, does not detect configuration, breaks user runtime if reconfigured

      To the best of my knowledge, wayland is the primary bottleneck here, however it is unlikely that a fix will be issued on their end, as it is a core principle of wayland not to allow visual programs to run as root and they will not patch this. As wayland is becoming the standard window manager for numerous linux distros, this needs to be accounted for, and this restriction needs to be either loosened, provided with a workaround internally, or removed.

      Several systems prevent running on XOrg due to underlying package conflicts, which leads to this issue being unsolvable at the user level, whether or not they have root access privileges.

      Attachments

        Activity

          People

            Unassigned Unassigned
            mopsyd Brian Dayhoff
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: