edubuntu-bugs team mailing list archive

["bodhi.zazen" <bodhi.zazen@xxxxxxxxx>]

Because lanuchpad clips comments I am re-posting so it does not so
easily get lost

@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 Edubuntu
Bugsquad, which is subscribed to italc 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