Xhost can be used to temporarily allow root access. If you are behind a firewall, you may consider them to be safe enough for your requirements. These methods will allow root to connect to a non-root user's X server, but present varying levels of security risks, especially if you run ssh. sux AUR (wrapper around su which will transfer your X credentials).These methods wrap the application in an elevation framework and drop the acquired privileges once it exits: This may be the object of a bug report to the upstream project.
#GEDIT NO PROTOCOL SPECIFIED CODE#
Applications should rather " defer the privileged operations to an auditable, self-contained, minimal piece of code that gets executed after doing a privilege escalation, and gets dropped when not needed". This should however " only be used for legacy programs", as pkexec(1) reminds. The proper, recommended way to run GUI applications under X with elevated privileges is to create a Polkit policy, as shown in this forum post. There are multiple ways of allowing root to do so however, if necessary. Xorgīy default, and for security reasons, root will be unable to connect to a non-root user's X server. The same effect can be attained via the Other locations server address bar. in nautilus or gedit, type Ctrl+l and then prepend the admin:// scheme to the resource path. I still have a permission denied with audio but video is fine (tested on Fedora 22 with SELinux ON).Tip: This can also be done from the application location bar/file selector: e.g.
#GEDIT NO PROTOCOL SPECIFIED HOW TO#
But there is one guy which explain clearly how to activate video hardware acceleration and audio when calling Firefox via sudo.
But I quickly found out that calling Firefox via sudo won't allow it to access audio nor the video hardware. PS: I did this in order to launch Firefox in a kind of "jail" (to avoid a vulnerability like for pdf.js in the future). In older times, when people typed xhost + and implicitely allowed everyone to use their X session, it was possible to display application on their screen for pranks -) not so much nowadays as people are less and less using X Window client/server architecture (at least for what I observe in the past 10 yers). X Window is very powerful in this regard and you can display remote applications locally by playing with the DISPLAY environment variable and xhost (but not limited to them). The si indicates that the rule is server side and it authorise the local user foo to display applications. xhost is a tool to manipulate the list of permissions. Other users do not have this permission unless you specify it. By default once you open a session (you graphically login), you (your user) are obviously allowed to commmunicate with the server and display applications. When you launch an application you request the X server authorisation to display it. xhost si:localuser:fooĪnd that was it, I was then able to launch Firefox (and other X application) using sudo and the user foo.īackground: On X Window, there is a client/server architecture. My solution was to simply add the user foo to the list of authorised access to the X server. no protocol specified & cannot open display) Sadly that command failed with the same error as in the question (i.e. I'm logged in as bar: ~]$ sudo -u foo -H firefox Let's say I want to start firefox using the user account foo. I had the same question as you but for a normal user.
0 kommentar(er)
