© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
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:/
PeterPall (peterpall) wrote on 2017-02-28: #3
According to https:/
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:/
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:/
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:/
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://
http://
http://
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:/
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,
reference 32 is here https:/
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:/
https:/
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://
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.