[Bug 1713313] Re: Unable to launch pkexec'ed applications on Wayland session

[bodhi.zazen]

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 Ubuntu
Studio Development, which is subscribed to ubuntustudio-default-settings
in Ubuntu.
https://bugs.launchpad.net/bugs/1713313

Title:
  Unable to launch pkexec'ed applications on Wayland session

To manage notifications about this bug go to:
https://bugs.launchpad.net/backintime/+bug/1713313/+subscriptions