First, let me say, I apologize for the tone of my last post. As an explanation, I have a long history with psusi. Phillip is very intelligent and can, at times, be very helpful.
Phillip, however, also has serious issues. He is arrogant and will never admit he is wrong. He also has his moods, I suspect he either has a personality disorder or is bipolar. When he gets in his moods he rants with blatant violations of the Ubuntu Code of Conduct. At these times he is impossible to reason with and usually escalates the situation. How do I know you might ask ? Because I served for some time as an Administrator on the Ubuntu Forums. Phillip was banned more than once for violations of the Ubuntu code of Conduct. I strongly suspect he has been banned for similar violations from other ubuntu sites / IRC as well. https://www.ubuntu.com/about/about-ubuntu/conduct On the forums, we would ban him for a period of time, 1-3 months depending on his behavior. Often we would start with a week or a month, but on his return he would start right back up with his violations, and we would extend the ban. Eventually he would cool down and we would restore his privileges. He would behave himself for a few weeks or months and then start to slip. We, the Ubuntu Forums Admins, would send a few PM to him, but his behavior would again escalate and he would again be banned. Frankly, I was shocked his post was not moderated and after 24 hours I over reacted. My over reaction is partially because of my history with Phillip, I endured endless personal insults and foul language from him during my time as an administrator on the Ubuntu Forms. My reaction is also because of the fact that I am no longer an Administrator on the Ubuntu Forums and, so I thought, if Launchpad is not going to enforce the Ubuntu Code of Conduct and regulate Phillip Susi (psusi) and his violations, I am not going to allow him to bully me. Last, I would also like to point out, I know a fair amount about Wayland. I have been using wayland for a few years now and was testing it in Fedora before it became default. I am very familiar with Wayland Security Development and having Phillip Susi (psusi) make a wild claim "Excuse my language Bodhi, but bull shit. You actually can run wayland apps as root just fine." shows his ignorance on wayland as well as a clear violation of the Code of conduct. This is an example of the behavior I have seen from Phillip in the past. He thinks he knows something, and rather than taking the time to explain his position, he resorts to personal insults and intimidation. When he acts this way he is 9 times out of 10 wrong, as he is in this case. Again, although Phillip has much to contribute he has major personality flaws and violates the Ubuntu Code of Conduct and I ask you to monitor his behavior very close. @psusi - Perhaps you can also add a few launchpad bug reports to your reading list: https://bugs.launchpad.net/debian/+source/synaptic/+bug/1551951 PeterPall (peterpall) wrote on 2017-02-28: #3 According to https://bugzilla.redhat.com/show_bug.cgi?id=1274451 not allowing graphical user interfaces to run as root is a design decision of wayland. The way to go for synaptic would be to run the graphical user interface as the unprivileged user who has called the program and then to use polkit in order to gain root rights for the portion of the program that does the actual installation and uninstallation of packages. Mark (1aunchpad-nct) wrote on 2017-10-30: #7 I have removed the duplicate marking on this bug. The bug this was marked as a duplicate of, bug #1712089, is a general report about the inability to run graphical applications as root under Wayland. As noted in comment #3, this is a Wayland design decision and Synaptic needs to be changed. I am concerned that if this bug remains as a duplicate it will be invisible to the Synaptic maintainers, delaying a fix. Absent objections to this change, I will change the duplicate settings on the other Synaptic related bugs currently dup'ed to bug #1712089 to be dup's of this. Importance needs to be set to High but I don't have permission to do that. And if we follow the bug reports https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/1712089 List of pkexec'ed applications is located in bug 1713313. List of packages which use su-to-root and gksu/gksudo is located in bug 1713311 NOTE: THIS IS BUG 1713311 Also in but 171089 Jean-Baptiste Lallement (jibel) wrote on 2017-08-21: #3 Thanks for your report. This is a known issue with wayland and documented on https://fedoraproject.org/wiki/How_to_debug_Wayland_problems#Graphical_applications_can.27t_be_run_as_root_from_terminal And from that Fedora link Graphical applications can't be run as root from terminal It is not possible to start graphical apps under the root account from terminal when using su or sudo. Apps which use polkit to request administrator permissions for just certain operations and only when needed are not affected (they are not started as root right away). The discussion is ongoing about the best approach to take, see bug 1274451 and "On running gui applications as root" thread in fedora-devel mailing list. Which links once again as a "Wont fix" bug report https://bugzilla.redhat.com/show_bug.cgi?id=1274451 There is a lot if information on that bug report as well, including links to the upstream source code. Olivier Fourdan 2015-10-30 05:43:14 EDT And this is on purpose obviously, I should have mentioned: http://cgit.freedesktop.org/xorg/xserver/commit/?id=c4534a3 http://cgit.freedesktop.org/xorg/xserver/commit/?id=4b4b908 http://cgit.freedesktop.org/xorg/xserver/commit/?id=76636ac Michael Catanzaro 2016-11-28 15:58:23 EST OK, to avoid the potential for misunderstood expectations: there are currently no plans to support running graphical apps with sudo under Wayland, and it seems quite unlikely that this will change anytime soon, so I'm going to close this as WONTFIX. psusi , this has been extensively discussed and is a work in progress. If you wish to learn a little something about wayland you can start with the basics https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Differences_between_Wayland_and_X Security Wayland isolates the input and output of every window, achieving confidentiality, integrity and availability in both cases; the original X design lacks these important security features,[32][33][34] although some extensions have been developed trying to mitigate it.[35][36][37] Also, with the vast majority of the code running in the client, less code needs to run with root privileges, improving security.[32] reference 32 is here https://lwn.net/Articles/517375/ There is a whole section on this issue Rootless Weston Traditionally, the X server has had to run with root privileges. Because the X window system is a large body of complex—and, in many cases, ancient—code, the fact that that code must run as root creates a window for attacks on a system. For this reason, it has long been a goal to rework the system to the point where root privilege is no longer need to run the X server. Although some progress has been made toward that goal, there is as yet no general solution the problem, and the X server still normally requires root privileges to run. The question then is how to avoid repeating this situation going forward, so that Weston does not require root privileges. Timothée ran through some of the factors blocking rootless Weston. One problem is that Weston needs access to /dev/input, which is accessible only to root. Root privilege is also required to send output to the screen and to support hot plugging of keyboards and screens. The solution he proposed was to isolate the code that requires root privileges into a separate small executable that is run with root privileges. In the case where Weston needed access to a privileged file, the small executable would then open the required file and pass a file descriptor via a UNIX domain socket to Weston. There was little comment on this proposal, which may signify that it seemed reasonable to everyone present. You can also read the wayland mailing lists. Here are links from the wayland security mailing list https://lists.freedesktop.org/archives/wayland-devel/2015-March/020474.html https://lists.freedesktop.org/archives/wayland-devel/2014-February/013359.html >From the second link Hi Guys, Following to the giant and impossible to read "Authorized clients" thread, I said I would take the time and write everything we talked about down, for convenience and to check I took everyone's idea and needs into account. I published the whole article on my blog [1] but I also wanted to copy the relevant information in this email, so as it could be easier for people to comment inline (since I'm really interested in feedback here), sorry for the markdown syntax but that's what I use for my website. I added Martin Graesslin in CC because he has shown interest in this and I'm sure his experience can benefit all of us. Hope something close to this proposal will be satisfactory to everyone and work can begin in this direction! Cheers, Martin Peres The blog is here http://mupuf.org/blog/2014/02/19/wayland-compositors- why-and-how-to-handle/ psusi I suggest you read the entire blog and mailing list. I will, however, quote one short section As no consensus on the policy can apparently be reached (as usual in security), we have all agreed that we needed to separate the policy from the code. This is very much alike Linux Security Modules (LSM) or X Access Control Extension (XACE). >From a software engineering point of view, we would work on a security library called Wayland Security Modules (name subject to changes) that Wayland compositors would call when a security decision would need to be made. The library would then load the wanted security policy, defined by a shared-object that I will refer to as the security backend. In the case of allowing a client to bind a restricted interface or not, the corresponding WSM hook should return ACCEPT, PROMPT or DENY, prompt meaning the compositor would have to ask the user if he wants to accept the risk or not. Let me stress out that prompting should be a last- resort measure as numerous studies have been made proving that unless asked very rarely, users will always allow the operation. Some additional hooks would also be needed in order to track the state of Wayland clients (open, close, etc…) but nothing too major should be needed. The compositors would just have to store this context in a void *security; attribute in the Wayland client structure. Finally, WSM could be extended to control the access to the clipboard and maybe other interfaces I haven’t thought about yet. You can read more about it if you wish on the Wayland mailing list, but, to summarize, the goal of Wayland is that NO APPLICATION WILL RUN AS ROOT . Applications will rather be given elevated privileges according to wayland security policy, which as of now remains a work in progress. The goals of this, and similar bug reports, are not to "fix" wayland as to allow people to run applications as root, via sudo, gksu, or any other means, but rather to have a centralized place to track all the problems, and then to triage them as needed. Some applications may be dropped. Fluxbox for example has no plans to port to wayland. Some applications may need to be triaged or co developed with Debian. Some applications the Ubuntu developers may choose to take on and pass patches upstream. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to hplip in Ubuntu. https://bugs.launchpad.net/bugs/1713313 Title: Unable to launch pkexec'ed applications on Wayland session Status in Back In Time: Fix Released Status in Boot-Info: Fix Committed Status in Boot-Repair: Fix Committed Status in GNOME Terminal: New Status in OS-Uninstaller: Fix Committed Status in Y PPA Manager: New Status in apport package in Ubuntu: New Status in apt-offline package in Ubuntu: New Status in backintime package in Ubuntu: Confirmed Status in budgie-welcome package in Ubuntu: Invalid Status in caja-admin package in Ubuntu: New Status in cinnamon package in Ubuntu: Invalid Status in ettercap package in Ubuntu: Confirmed Status in gdebi package in Ubuntu: Confirmed Status in gdm3 package in Ubuntu: New Status in gnunet-gtk package in Ubuntu: Confirmed Status in gparted package in Ubuntu: Invalid Status in gui-ufw package in Ubuntu: Confirmed Status in guidedog package in Ubuntu: New Status in hplip package in Ubuntu: Confirmed Status in italc package in Ubuntu: New Status in laptop-mode-tools package in Ubuntu: New Status in lightdm-gtk-greeter-settings package in Ubuntu: Confirmed Status in nautilus-admin package in Ubuntu: New Status in needrestart-session package in Ubuntu: Confirmed Status in nemo package in Ubuntu: Confirmed Status in policykit-1 package in Ubuntu: Invalid Status in scanmem package in Ubuntu: New Status in scap-workbench package in Ubuntu: Confirmed Status in sirikali package in Ubuntu: Fix Released Status in synaptic package in Ubuntu: Confirmed Status in thunar package in Ubuntu: New Status in tuned package in Ubuntu: New Status in ubuntustudio-controls package in Ubuntu: New Status in ubuntustudio-default-settings package in Ubuntu: Invalid Status in update-notifier package in Ubuntu: New Status in xdiagnose package in Ubuntu: Confirmed Status in xubuntu-default-settings package in Ubuntu: Invalid Status in zulucrypt package in Ubuntu: Fix Released Bug description: ***************************** Main upstream discussion & fixes example to deal with wayland: https://bugzilla.gnome.org/show_bug.cgi?id=776437 ***************************** ******************************************************************************************************************************************** Steps to reproduce: 1. Install Ubuntu 17.10 2. Install backintime-qt4 or gparted application from above list (full may be acquired from https://codesearch.debian.net/search?q=pkexec+filetype%3Adesktop+path%3A*%2Fapplications%2F*&perpkg=1&page=4 ) 3a. Try to launch backintime-qt4 from shortcut "Back In Time (root)" (located in /usr/share/applications/backintime-qt4-root.desktop, it uses pkexec ($ cat /usr/share/applications/backintime-qt4-root.desktop | grep Exec Exec=pkexec backintime-qt4) 3b. Try to launch Gparted from shortcut "GParted" (located in /usr/share/applications/gparted.desktop, it uses gparted-pkexec) 4a.1. Back In Time does not start from GUI. 4a.2. Back In Time shows error message in console: 4b. gparted-pkexec does not start, reports error $ gparted-pkexec Created symlink /run/systemd/system/-.mount → /dev/null. Created symlink /run/systemd/system/run-user-1000.mount → /dev/null. Created symlink /run/systemd/system/run-user-121.mount → /dev/null. Created symlink /run/systemd/system/tmp.mount → /dev/null. No protocol specified (gpartedbin:12831): Gtk-WARNING **: cannot open display: :0 Removed /run/systemd/system/-.mount. Removed /run/systemd/system/run-user-1000.mount. Removed /run/systemd/system/run-user-121.mount. Removed /run/systemd/system/tmp.mount. $ pkexec backintime-qt4 Back In Time Version: 1.1.12 Back In Time comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; type `backintime --license' for details. No protocol specified app.py: cannot connect to X server :0 Expected results: * backintime-qt4 may be run as root Actual results: * unable to run backintime-qt4 as root Workaround: * setting "xhost +si:localuser:root" helps. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: backintime-qt4 1.1.12-2 ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5 Uname: Linux 4.12.0-11-generic i686 ApportVersion: 2.20.6-0ubuntu7 Architecture: i386 CurrentDesktop: GNOME Date: Sun Aug 27 14:23:14 2017 InstallationDate: Installed on 2017-08-26 (0 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha i386 (20170826) PackageArchitecture: all SourcePackage: backintime UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/backintime/+bug/1713313/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
