Hi.
I am using OpenSuse 11.1 and i cant find a way to make sudo open X programs like gedit
diego@linux-8mmd:~> sudo gedit
No protocol specified
(gedit:5500): Gtk-WARNING **: cannot open display: :0.0
diego@linux-8mmd:~> sudo xhost +localhost
xhost: unable to open display ""
gnomesu works, but it asks for password.
Hi
Use xdg-su, for example;
xdg-su -c "gedit /etc/hosts"
–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.1 x86 Kernel 2.6.27.7-9-default
up 3 days 9:58, 3 users, load average: 0.30, 0.21, 0.24
GPU GeForce 6600 TE/6200 TE - Driver Version: 180.22
thanks, better than gnomesu, but still asking for password, and is more complicated to type in the console.
You force the same error twice. sudo lets a process run as root and is not allowed to open a window on the display you diego have.
Then you use sudo again running xhost as root. But root can not help you here, it has no display. diego must run xhost. So leave out the sudo:
diego@linux-8mmd:~> xhost +
Now you, diego, allow everybody (including root) to open a window on your display.
Thank you.
Very good explanation.
I just did “xhost +” as user “diego” and now sudo is able to run X programs.
Now just to ask… is there a way to only allow sudo in the xhost’s list?
It is not the command *sudo, *but the user *root *you have to allow. And indeed, a plain *xhost + *does allow “anybody” to open windows before your very nose 
. Now do not be to afraid of this, Those from other systems are normaly blocked from doing so by your firewall. And those from inside your system … well, when this is a pc there will not be very many.
But yes you can restrict. Your *+localhost *is restricting it to those comming from localhost (127.0.0.1), that is “inside”.
You could read the man xhost page (as I did). It talks about usernames, but I can not find out how . But as said, *localhost *may be enough security.
BTW I think (but not quite sure, please test) that once a + entry is added to the list, it stayes there over the following log-ins (somewhere in a .X* or .x* file in your home directory). Just a
xhost
will tel you what the situation is. Eventualy first do a
xhost -
before a more restricting
xhost +localhost
Hi Friends,
I too need to run gui application from normal user account but with root privileges.
I tried xhost + and then sudo gui_app.sh ( I have already added relevant entry in /etc/sudores file )
but it give Error: Can’t open display:
(echo $DISPLAY gives localhost:11.0)
Any guide to fix this issue.
You can’t and shouldn’t run gui applications with sudo.
Use kdesu, gnomesu or xdg-su instead.
F.e.:
xdg-su -c *program
*kdesu *program
*gnomesu *program*
On Tue, 28 May 2013 18:16:03 +0000, dhananjaya amarakoon wrote:
> Hi Friends,
> I too need to run gui application from normal user account but with root
> privileges.
> I tried xhost + and then sudo gui_app.sh ( I have already added
> relevant entry in /etc/sudores file )
> but it give Error: Can’t open display:
>
> (echo $DISPLAY gives localhost:11.0)
>
> Any guide to fix this issue.
Use gnomesu or kdesu instead of sudo.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
HI wolfi323
thanks for the support. but it request root password
but my requirement is open a gui application ( with root permission ) from normal user without given root password. is there any possibility of getting this done.
Dhananjaya
On 05/29/2013 05:56 AM, dhananjaya amarakoon wrote:
>
> is there any possibility of getting this done.
no, not easily and you really don’t wanna do that anyway. because the
user wanting to do root tasks needs to know the root password!
otherwise anyone who touches the machine (physically or via remote)
can easily be root…not a healthy situation for your system.
ok, now i see you have only been here a few days…-=WELCOME=- new
poster…you didn’t mention a Linux experience level, so if this
post sounds like i think you know nothing: it only displays my
ignorance of your well cloaked super powers…so, can i guess you
have very little experience in Linux and a lot of experience in one
or two other operating systems? or which other *nix-like systems
are you familiar with?
if little or no previous Linux experience you probably need to read
though http://tinyurl.com/593e4c as a minimum, and also
http://tinyurl.com/8b9s6
if you have Ubuntu/Debian experience you might find differences
between those and openSUSE both enlightening and interesting, here
http://tinyurl.com/ubuntu-to-openSUSE
http://tinyurl.com/Ubuntu-Differences
Well there is, at least for kdesu: Default kdesu to use sudo and not su | Free Techie Blog
So run this as the respective user:
kwriteconfig --file kdesurc --group super-user-command --key super-user-command sudo
and kdesu should use sudo instead of su, and thus respect /etc/sudoers. Note that you may have to kill kdesud first for this to have effect, or logout/reboot.
Not necessarily. You can restrict passwordless sudo to certain users/groups in /etc/sudoers, or even just to certain commands…
On 2013-05-29 09:08, dd wrote:
> On 05/29/2013 05:56 AM, dhananjaya amarakoon wrote:
>>
>> is there any possibility of getting this done.
>
> no, not easily and you really don’t wanna do that anyway. because the
> user wanting to do root tasks needs to know the root password!
No, that is what sudo is about really 
Mr. Root sets it up so that it asks for the user password, of certain
users, in order to run certain tasks - and only those tasks. That’s the
whole point! If I know root’s password, I do not need sudo, I get “su”
and done.
The idea is that some users are empowered to do some tasks that need
root’s powers without having the key to the whole house 
Notice this paragraph in the sudoers file:
> ## In the default (unconfigured) configuration, sudo asks for the root password.
> ## This allows use of an ordinary user account for administration of a freshly
> ## installed system. When configuring sudo, delete the two
> ## following lines:
> Defaults targetpw # ask for the password of the target user i.e. root
> ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'!
The tricks normally done here using sudo work because sudo is NOT
configured!
A properly configured sudoers would have:
# Defaults targetpw # ask for the password of the target user i.e. root
# ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults
targetpw'!
.... and then:
cer Telcontar= (root) /usr/bin/baobab
And then you do:
> cer@Telcontar:~> sudo /usr/bin/baobab
> cer's password:
>
> ** (baobab:5087): CRITICAL **: Unable to parse option: Cannot open display:
> cer@Telcontar:~>
which is dhananjaya_amarakoon problem precisely.
A text program works:
cer@Telcontar:~> sudo /usr/bin/zypper ref
Repository 'OBS: Games' is up to date.
Repository 'OBS: KDE:KDE3' is up to date.
Repository 'OBS KDE:Distro:Stable' is up to date.
Retrieving repository 'OBS: KDE: Extra' metadata /]
The password is not asked for because I have used the same terminal, and
my credentials are valid for some minutes.
dhananjaya_amarakoon is doing it correctly, and this worked previously.
It worked for me, I did it the same way years ago - that’s why I have
the baobab entry in there, and a few more.
The problem is that the graphical alternatives to sudo use “su” as
backend instead of sudo. Maybe wolfi323 trick for kdesu works.
And maybe again, there is a setting in the sudoers file that would make
it work. What variable do we need to keep?
Reading the man page, it hints at using “sudo -i”. Let’s try:
> cer@Telcontar:~> sudo -i /usr/bin/baobab
> cer's password:
> Sorry, user cer is not allowed to execute '/bin/bash -c /usr/bin/baobab' as root on Telcontar.
> cer@Telcontar:~>
Ok, not yet. Modifying sudoers… no, that’s not enough.
> cer@Telcontar:~> sudo -i /usr/bin/baobab
> cer's password:
>
> ** (baobab:6873): CRITICAL **: Unable to parse option: Cannot open display:
> cer@Telcontar:~>
Maybe there is something else we need to do to use sudo with graphical
tools.
Reading again the man page, the “-i” is incorrect. It says:
# Run X applications through sudo; HOME is used to find the
# .Xauthority file. Note that other programs use HOME to find
# configuration files and this may lead to privilege escalation!
Defaults env_keep += "DISPLAY HOME"
But it does not work:
> cer@Telcontar:~> sudo /usr/bin/baobab
> No protocol specified
>
> ** (baobab:7053): CRITICAL **: Unable to parse option: Cannot open display:
> cer@Telcontar:~>
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
It does work. I just tried it (on 12.3).
And maybe again, there is a setting in the sudoers file that would make
it work. What variable do we need to keep?
Reading the man page, it hints at using “sudo -i”. Let’s try:
cer@Telcontar:~> sudo -i /usr/bin/baobab
cer’s password:
Sorry, user cer is not allowed to execute ‘/bin/bash -c /usr/bin/baobab’ as root on Telcontar.
cer@Telcontar:~>
Ok, not yet. Modifying sudoers… no, that’s not enough.
cer@Telcontar:~> sudo -i /usr/bin/baobab
cer’s password:** (baobab:6873): CRITICAL **: Unable to parse option: Cannot open display:
cer@Telcontar:~>
Maybe there is something else we need to do to use sudo with graphical
tools.
Reading again the man page, the “-i” is incorrect. It says:
Run X applications through sudo; HOME is used to find the
.Xauthority file. Note that other programs use HOME to find
configuration files and this may lead to privilege escalation!
Defaults env_keep += “DISPLAY HOME”
But it does not work:
cer@Telcontar:~> sudo /usr/bin/baobab
No protocol specified** (baobab:7053): CRITICAL **: Unable to parse option: Cannot open display:
cer@Telcontar:~>
“sudo -i” works as well. But you have to grant access to your X with xhost (as already has been mentioned) and you have to specify the display to use with “-display”, f.e.:
wolfi@amiga:~> sudo -i kwrite
kwrite: cannot connect to X server
wolfi@amiga:~> sudo -i kwrite -display :0
wolfi@amiga:~>
And the kwrite window appears…
On 2013-05-29 16:06, wolfi323 wrote:
> “sudo -i” works as well. But you have to grant access to your X with
> xhost (as already has been mentioned) and you have to specify the
> display to use with “-display”, f.e.:
>
> Code:
> --------------------
> wolfi@amiga:~> sudo -i kwrite
> kwrite: cannot connect to X server
> wolfi@amiga:~> sudo -i kwrite -display :0
> wolfi@amiga:~>
> --------------------
> And the kwrite window appears…
not here:
> cer@Telcontar:~> sudo /usr/bin/baobab -display :0
> cer's password:
>
> ** (baobab:14934): CRITICAL **: Unable to parse option: Unknown option -display
> cer@Telcontar:~> sudo -i /usr/bin/baobab -display :0
> Sorry, user cer is not allowed to execute '/bin/bash -c /usr/bin/baobab -display :0' as root on Telcontar.
> (reverse-i-search)`bash': size /bin/^Csh
> (reverse-i-search)`sudo': ^Cdo /usr/bin/zypper ref
> cer@Telcontar:~> sudo -i /bin/bash -c /usr/bin/baobab -display :0
> Sorry, user cer is not allowed to execute '/bin/bash -c /bin/bash -c /usr/bin/baobab -display :0' as root on Telcontar.
> cer@Telcontar:~> sudo -i /bin/bash -c /usr/bin/baobab -display :0
> Sorry, user cer is not allowed to execute '/bin/bash -c /bin/bash -c /usr/bin/baobab -display :0' as root on Telcontar.
> cer@Telcontar:~> sudo -i /bin/bash -c /usr/bin/baobab -display :0
> Sorry, user cer is not allowed to execute '/bin/bash -c /bin/bash -c /usr/bin/baobab -display :0' as root on Telcontar.
> cer@Telcontar:~
And:
visudo: >>> /etc/sudoers: syntax error near line 106 <<<
line is:
cer Telcontar= (root) /bin/bash -c /usr/bin/baobab -display :0
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
On 05/29/2013 10:36 AM, wolfi323 wrote:
>
> Not necessarily. You can restrict passwordless sudo to certain
> users/groups in /etc/sudoers, or even just to certain commands…
sure, if the admin knows what’s what! does the OP?
or, are you gonna teach him?
there was a reason i wrote “. . . not easily . . .”
for Carlos:
yes i know what sudo is for and it can be setup, and that it is not
default set up to do what the OP wants, easily…
if you wish to teach him, go ahead…
lets see if the OP tells about his experience level, then the
teachers here will know at what level to begin the tutelage…
–
dd
Well, I don’t know baobab but ‘-display’ is a standard option for KDE programs, so every KDE program supports it.
Maybe baobab has a similar option with a different name? (run “baobab --help” to see a list of options)
Or maybe setting the $DISPLAY variable works:
sudo -i DISPLAY=:0 baobab
And:
visudo: >>> /etc/sudoers: syntax error near line 106 <<<
line is:
cer Telcontar= (root) /bin/bash -c /usr/bin/baobab -display :0
I think you would have to put quotes around the command.
On 2013-05-29 22:46, wolfi323 wrote:
>
> robin_listas;2561089 Wrote:
>> not here:
> Well, I don’t know baobab but ‘-display’ is a standard option for KDE
> programs, so every KDE program supports it.
It is a gnome program.
> Maybe baobab has a similar option with a different name? (run “baobab
> --help” to see a list of options)
Well, actually, it has. But what we need is a combination to give for
sudo, not for the programs it calls. Some programs might not have it.
And, it does not work:
> cer@Telcontar:~> sudo /bin/bash -c /usr/bin/baobab --display :0
> cer's password:
>
> ** (baobab:19716): CRITICAL **: Unable to parse option: Cannot open display:
> cer@Telcontar:~>
> cer@Telcontar:~> sudo -i /usr/bin/baobab --display :0
> No protocol specified
>
> ** (baobab:19755): CRITICAL **: Unable to parse option: Cannot open display: :0
> cer@Telcontar:~>
> cer@Telcontar:~> sudo /usr/bin/baobab --display :0
> No protocol specified
>
> ** (baobab:19795): CRITICAL **: Unable to parse option: Cannot open display: :0
> cer@Telcontar:~>
Or maybe setting the $DISPLAY variable works:
You can tell sudo to transfer the DISPLAY variable, that is not the
problem. Look, it is correctly set:
> cer@Telcontar:~> sudo /usr/bin/env | grep -i display
> DISPLAY=:0
> cer@Telcontar:~>
>
> however:
>
> cer@Telcontar:~> sudo /usr/bin/baobab
> No protocol specified
>
> ** (baobab:19956): CRITICAL **: Unable to parse option: Cannot open display:
> cer@Telcontar:~>
I think you would have to put quotes around the command.
No, it needed escaping the colon.
xhost doesn’t work, either. The man page says:
+]name The given name (the plus sign is optional) is
added to the list allowed to connect to the
X server. The name can be a host name or a user name.
But:
> cer@Telcontar:~> xhost +root
> xhost: bad hostname "root"
> cer@Telcontar:~> man xhost
> cer@Telcontar:~> xhost +root@localhost
> root@localhost being added to access control list
> cer@Telcontar:~> sudo /usr/bin/baobab
> cer's password:
> No protocol specified
>
> ** (baobab:20272): CRITICAL **: Unable to parse option: Cannot open display:
> cer@Telcontar:~>
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
On 2013-05-29 19:24, dd wrote:
> for Carlos:
>
> yes i know what sudo is for and it can be setup, and that it is not
> default set up to do what the OP wants, easily…
Sorry, I misunderstood.
> if you wish to teach him, go ahead…
>
> lets see if the OP tells about his experience level, then the teachers
> here will know at what level to begin the tutelage…
He has the same problem as I have, I can not make it work. And IIRC, it
worked years ago.
The only way I know how to use these tools is using root password, with
su, or setting the suid bit in the file, and only give execution
permission to a group.
It must be a problem with xhost, or another variable that must be passed
besides DISPLAY.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)