sudo doesnt open X programs

[wolfi323]

@robin_listas

It is a gnome program.

I knew that. But I don’t have it installed and thus don’t know which command line options it accepts (and couldn’t check).

> 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.

But the program opens the window, so the program must know where to open it, not sudo.

And, it does not work:

…

xhost doesn’t work, either. The man page says:
…

It did work here. I just ran “xhost +” (yes, I know that’s insecure blah blah blah…, it was just for testing purposes).
Then “sudo -i kwrite” still gave an error message but “sudo -i kwrite -display :0” worked. And any other KDE program should as well.
I haven’t tried any GNOME programs.

I also haven’t tried to change anything in /etc/sudoers, I just tried to get a KDE program to run with sudo and I succeeded.

In the end I have to say: Just use kdesu, that one works!
There’s also gksu, but that’s obsolete it seems; it’s being rewritten at the moment with PolicyKit in mind.

[wolfi323]

@robin_listas

or setting the suid bit in the file, and only give execution
permission to a group.

And don’t you have the problem with this as well that it isn’t being granted access to the X display?
I had when I tried that on 12.3, so it didn’t work…

[robin_listas]

On 2013-05-30 01:06, wolfi323 wrote:
>
> robin_listas;2561178 Wrote:
>> or setting the suid bit in the file, and only give execution
>> permission to a group.
> And don’t you have the problem with this as well that it isn’t being
> granted access to the X display?
> I had when I tried that on 12.3, so it didn’t work…

With “su -”, I have tried and it works. With suid bit… dunno… yes,
it also works.

Telcontar:~ # chmod u+s /usr/bin/baobab
Telcontar:~ # l /usr/bin/baobab
-rwsr-xr-x 1 root root 128792 Oct 30  2011 /usr/bin/baobab*
Telcontar:~ # logout
cer@Telcontar:~> baobab

....

(baobab:22322): GVFS-RemoteVolumeMonitor-WARNING **: cannot connect to
the session bus: org.freedesktop.DBus.Error.NotSupported: Unable to
autolaunch when setuid

....

but program is running just fine.

(baobab is a usage display of your filesystem. You can see where
diskspace is wasted, and it is good at just that. But has to be run as
root to be meaningful)

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

[robin_listas]

On 2013-05-30 00:56, wolfi323 wrote:
>
> robin_listas;2561176 Wrote:
>> It is a gnome program.
> I knew that. But I don’t have it installed and thus don’t know which
> command line options it accepts (and couldn’t check).

Ok.

>>> 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.
> But the program opens the window, so the program must know where to
> open it, not sudo.

Sudo can tell it, via display variable - and you see it is passed.

>> And, it does not work:
>>
>> …
>>
>> xhost doesn’t work, either. The man page says:
>> …
> It did work here. I just ran “xhost +” (yes, I know that’s insecure
> blah blah blah…, it was just for testing purposes).
> Then “sudo -i kwrite” still gave an error message but “sudo -i kwrite
> -display :0” worked. And any other KDE program should as well.

Notice that my sudo is configured to use my user password, not root’s,
same as the OP. Ok, I’ll try kwrite.

cer@Telcontar:~> xhost
access control enabled, only authorized clients can connect
NIS:root@localhost
cer@Telcontar:~> xhost +root
xhost:  bad hostname "root"
cer@Telcontar:~> xhost +root@localhost
root@localhost being added to access control list
cer@Telcontar:~> xhost
access control enabled, only authorized clients can connect
NIS:root@localhost
cer@Telcontar:~> sudo /usr/bin/kwrite
No protocol specified
kwrite: cannot connect to X server :0
cer@Telcontar:~>

cer@Telcontar:~> sudo -i /usr/bin/kwrite
Sorry, user cer is not allowed to execute '/bin/bash -c /usr/bin/kwrite'
as root on Telcontar.
cer@Telcontar:~> sudo -i /usr/bin/kwrite
No protocol specified
kwrite: cannot connect to X server :0
cer@Telcontar:~> sudo -i /usr/bin/kwrite -display :0
Sorry, user cer is not allowed to execute '/bin/bash -c /usr/bin/kwrite
-display :0' as root on Telcontar.
cer@Telcontar:~>

edit sudoers to allow.

cer@Telcontar:~> sudo -i /usr/bin/kwrite -display :0
No protocol specified
kwrite: cannot connect to X server :0
cer@Telcontar:~>
cer@Telcontar:~> sudo /usr/bin/kwrite -display :0
No protocol specified
kwrite: cannot connect to X server :0
cer@Telcontar:~>

In the end I have to say: Just use kdesu, that one works!
There’s also gksu, but that’s obsolete it seems; it’s being rewritten
at the moment with PolicyKit in mind.

It does not work here (im running xfce). It asks for root password. If I
do the change you suggested:

> cer@Telcontar:~> kwriteconfig --file kdesurc --group super-user-command --key super-user-command sudo
> cer@Telcontar:~> kdesu /usr/bin/kwrite
> kbuildsycoca4 running...

then it asks for my user password, but denies me access. The message is:

Permission denied
Possibly incorrect password, please try again
On some systems, you need to be in special group (often: wheel) to use
this progam.

Yes, I’m in that group.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

[wolfi323]

@robin_listas

> But the program opens the window, so the program must know where to
> open it, not sudo.

Sudo can tell it, via display variable - and you see it is passed.

Yeah, but it doesn’t seem to work…

cer@Telcontar:~> xhost
access control enabled, only authorized clients can connect
NIS:root@localhost
cer@Telcontar:~> xhost +root
xhost: bad hostname “root”
cer@Telcontar:~> xhost +root@localhost
root@localhost being added to access control list
cer@Telcontar:~> xhost
access control enabled, only authorized clients can connect
NIS:root@localhost
cer@Telcontar:~> sudo /usr/bin/kwrite
No protocol specified
kwrite: cannot connect to X server :0
cer@Telcontar:~>

As I said, I used “xhost +” for testing. Try that. (but this completely disables access control)

In the end I have to say: Just use kdesu, that one works!
There’s also gksu, but that’s obsolete it seems; it’s being rewritten
at the moment with PolicyKit in mind.

It does not work here (im running xfce). It asks for root password. If I
do the change you suggested:

cer@Telcontar:~> kwriteconfig --file kdesurc --group super-user-command --key super-user-command sudo
cer@Telcontar:~> kdesu /usr/bin/kwrite
kbuildsycoca4 running…

then it asks for my user password, but denies me access. The message is:

Permission denied
Possibly incorrect password, please try again
On some systems, you need to be in special group (often: wheel) to use
this progam.

Yes, I’m in that group.

Well, in my test I granted my user full powers without entering a password. (a line “wolfi ALL=(ALL) NOPASSWD: ALL”)
And it worked, kdesu didn’t ask for a password, kwrite started as root.

Sorry, can’t do more testing until Sunday…

[robin_listas]

On 2013-05-30 12:36, wolfi323 wrote:
> robin_listas;2561197 Wrote:

>>> But the program opens the window, so the program must know where to
>>> open it, not sudo.
>>
>> Sudo can tell it, via display variable - and you see it is passed.
> Yeah, but it doesn’t seem to work…

That is the problem. It is not “DISPLAY”, it is something else.

> As I said, I used “xhost +” for testing. Try that. (but this completely
> disables access control)

I might, if I knew how to restore it back to defaults later.

> Well, in my test I granted my user full powers without entering a
> password. (a line “wolfi ALL=(ALL) NOPASSWD: ALL”)
> And it worked, kdesu didn’t ask for a password, kwrite started as root.

Not here. Tried that line, no go. It still asks for my password, and
does not run:

cer@Telcontar:~> sudo /usr/bin/kwrite -display :0
cer's password:
No protocol specified
kwrite: cannot connect to X server :0
cer@Telcontar:~>

Without the line, it asks for my password, then refuses to authorize me.

cer@Telcontar:~> sudo /usr/bin/kwrite -display :0
cer's password:
Sorry, user cer is not allowed to execute '/usr/bin/kwrite -display :0'
as root on Telcontar.
cer@Telcontar:~>

> Sorry, can’t do more testing until Sunday…

Ok… for me, it is an intellectual problem, not a real need. It is a
real problem for the OP, but he has disappeared.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

[wolfi323]

@robin_listas

> As I said, I used “xhost +” for testing. Try that. (but this completely
> disables access control)

I might, if I knew how to restore it back to defaults later.

To enable access control again, run “xhost -”.

> Well, in my test I granted my user full powers without entering a
> password. (a line “wolfi ALL=(ALL) NOPASSWD: ALL”)
> And it worked, kdesu didn’t ask for a password, kwrite started as root.

Not here. Tried that line, no go. It still asks for my password, and
does not run:

But in this case you did run sudo. (not kdesu)
And if it still asks for a password after adding that line, there must be some conflict/error in your /etc/sudoers.
And it would ask for a password for running a non-gui program as well…

I hope you did change the username from “wolfi” to “cer” in that line?

[robin_listas]

On 2013-05-30 15:16, wolfi323 wrote:
>
> robin_listas;2561305 Wrote:
>>> As I said, I used “xhost +” for testing. Try that. (but this completely
>>> disables access control)
>>
>> I might, if I knew how to restore it back to defaults later.
> To enable access control again, run “xhost -”.

Right. Then, with “xhost +” it works. The problem then is that “xhost
+root” is not accepted as valid command, and “xhost +root@localhost” is
accepted but does not work.

>> Not here. Tried that line, no go. It still asks for my password, and
>> does not run:
> But in this case you did run sudo. (not kdesu)
> And if it still asks for a password after adding that line, there must
> be some conflict/error in your /etc/sudoers.
> And it would ask for a password for running a non-gui program as
> well…

Today it did not ask for the password. There are some settings with sudo
that need to timeout. I did try with a new xterm, but it was not enough.

> I hope you did change the username from “wolfi” to “cer” in that line?
>

Yes! :-))

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

[wolfi323]

@robin_listas

On 2013-05-30 15:16, wolfi323 wrote:
>
> robin_listas;2561305 Wrote:
>>> As I said, I used “xhost +” for testing. Try that. (but this completely
>>> disables access control)
>>
>> I might, if I knew how to restore it back to defaults later.
> To enable access control again, run “xhost -”.

Right. Then, with “xhost +” it works. The problem then is that “xhost
+root” is not accepted as valid command, and “xhost +root@localhost” is
accepted but does not work.

I had a look at the xhost manpage now. That “name” in “xhost +]name” doesn’t refer to a username but a host name.
So with “xhost +localhost” you would allow your user open windows from localhost which is of course superfluous.
And a ‘@’ in the name would cause the name to be interpreted as “Secure RPC network name” (nis).
From the man page:

   For backward compatibility with pre-R6 xhost, names that contain an at-
   sign (@) are assumed to be in  the  nis  family.

That’s not what is wanted here either…

I have not yet found a way to grant root access to the Xserver. Maybe with xauth?

And another thing:
Explicitely setting the DISPLAY variable does work also with GNOME applications.

sudo DISPLAY=:0 gedit

works here (after calling “xhost +” of course).

@robin_listas

> Sorry, can’t do more testing until Sunday…

Ok… for me, it is an intellectual problem, not a real need. It is a
real problem for the OP, but he has disappeared.

Well, I guess for the OP the solution using kdesu with sudo backend should be OK…

[robin_listas]

On 2013-06-05 14:06, wolfi323 wrote:
>
> robin_listas;2561449 Wrote:

>> Right. Then, with “xhost +” it works. The problem then is that “xhost
>> +root” is not accepted as valid command, and “xhost +root@localhost” is
>> accepted but does not work.
> I had a look at the xhost manpage now. That “name” in “xhost +]name”
> doesn’t refer to a username but a host name.

No, look:

+]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.

“host or a user name” - it says so clearly.

I have not yet found a way to grant root access to the Xserver. Maybe
with xauth?

I don’t understand the manual. Apparently “xhost list” would give the
list, but:

cer@Telcontar:~> xauth list
Telcontar.valinor:0  MIT-MAGIC-COOKIE-1  771d792bd54a483c99ec42fcc81b660e
[fe80::221:85ff:fe16:2d0b]:0  MIT-MAGIC-COOKIE-1
771d792bd54a483c99ec42fcc81b660e
Telcontar/unix:0  MIT-MAGIC-COOKIE-1  771d792bd54a483c99ec42fcc81b660e
nimrodel/unix:10  MIT-MAGIC-COOKIE-1  9436c516928ffeef0d016756be88fd03
Telcontar/unix:11  MIT-MAGIC-COOKIE-1  bbb5c0ce60d974f1d2a11f8bd2a51223
Telcontar/unix:1  MIT-MAGIC-COOKIE-1  c4e3a8476e6c7b41bc8638e042c88232
Telcontar.valinor:1  MIT-MAGIC-COOKIE-1  c4e3a8476e6c7b41bc8638e042c88232
localhost:1  MIT-MAGIC-COOKIE-1  c4e3a8476e6c7b41bc8638e042c88232
localhost:0  MIT-MAGIC-COOKIE-1  9cb8f93edd64c10ae14ac72db8f82153

i don’t see how to authorize a user.

> And another thing:
> Explicitely setting the DISPLAY variable does work also with GNOME
> applications.
>
> Code:
> --------------------
> sudo DISPLAY=:0 gedit
> --------------------
>
> works here (after calling “xhost +” of course).

It works here without the DISPLAY part, after “xhost +”. That’s the
crucial part, not the display variable.

But “xhost +root@localhost” does not.

> robin_listas;2561305 Wrote:
>>> Sorry, can’t do more testing until Sunday…
>>
>> Ok… for me, it is an intellectual problem, not a real need. It is a
>> real problem for the OP, but he has disappeared.
> Well, I guess for the OP the solution using kdesu with sudo backend
> should be OK…

He hasn’t said a word.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

[hendersj]

On Wed, 05 Jun 2013 12:06:02 +0000, wolfi323 wrote:

> So with “xhost +localhost” you would allow your user open windows from
> localhost which is of course superfluous.

Actually, it isn’t - I’ve used this in the past because the default is
only the current user on the current host can open windows. Adding
+localhost lets any user on the local machine open windows in the GUI.

Jim

–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

[robin_listas]

On 2013-06-05 18:42, Jim Henderson wrote:
> On Wed, 05 Jun 2013 12:06:02 +0000, wolfi323 wrote:
>
>> So with “xhost +localhost” you would allow your user open windows from
>> localhost which is of course superfluous.
>
> Actually, it isn’t - I’ve used this in the past because the default is
> only the current user on the current host can open windows. Adding
> +localhost lets any user on the local machine open windows in the GUI.

It does not work here.

cer@Telcontar:~> xhost -
access control enabled, only authorized clients can connect
cer@Telcontar:~> xhost +localhost
localhost being added to access control list
cer@Telcontar:~> sudo /usr/bin/baobab
cer's password:
No protocol specified

** (baobab:5427): CRITICAL **: Unable to parse option: Cannot open display:
cer@Telcontar:~> xhost +
access control disabled, clients can connect from any host
cer@Telcontar:~> sudo /usr/bin/baobab
cer@Telcontar:~>   (success)
cer@Telcontar:~> xhost -
access control enabled, only authorized clients can connect
cer@Telcontar:~> xhost +localhost
localhost being added to access control list
cer@Telcontar:~> xhost +Telcontar
Telcontar being added to access control list
cer@Telcontar:~> xhost +Telcontar.valinor
Telcontar.valinor being added to access control list
cer@Telcontar:~> sudo /usr/bin/baobab
No protocol specified

** (baobab:5524): CRITICAL **: Unable to parse option: Cannot open display:
cer@Telcontar:~> xhost -
access control enabled, only authorized clients can connect
cer@Telcontar:~>

The only combination that works is plain unlimited “xhost +”.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

[wolfi323]

@robin_listas

On 2013-06-05 14:06, wolfi323 wrote:
> I had a look at the xhost manpage now. That “name” in “xhost +]name”
> doesn’t refer to a username but a host name.

No, look:

+]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.

“host or a user name” - it says so clearly.

Well, not here on my 12.3 system:

   +]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 complete name (See NAMES for more details).

And the NAMES section:

NAMES
A complete name has the syntax ``family:name’’ where the families are
as follows:

   inet      Internet host (IPv4)
   inet6     Internet host (IPv6)
   dnet      DECnet host
   nis       Secure RPC network name
   krb       Kerberos V5 principal
   local     contains only one name, the empty string
   si        Server Interpreted


   The family is case insensitive.  The format of the name varies with the
   family.


   When Secure RPC is being used, the network independent  netname  (e.g.,
   "nis:unix.uid@domainname")  can  be  specified,  or a local user can be
   specified  with  just  the  username  and  a  trailing  at-sign  (e.g.,
   "nis:pat@").


   For backward compatibility with pre-R6 xhost, names that contain an at-
   sign (@) are assumed to be in  the  nis  family.   Otherwise  they  are
   assumed to be Internet addresses. If compiled to support IPv6, then all
   IPv4 and IPv6 addresses returned by getaddrinfo(3)  are  added  to  the
   access list in the appropriate inet or inet6 family.


   The  local family specifies all the local connections at once. However,
   the server interpreted address "si:localuser:username" can be  used  to
   specify a single local user. (See the Xsecurity(7) manual page for more
   details.)


   Server interpreted addresses consist of a case-sensitive type tag and a
   string  representing a given value, separated by a colon.  For example,
   "si:hostname:almas" is a server interpreted address of  type  hostname,
   with a value of almas.   For more information on the available forms of
   server interpreted addresses, see the Xsecurity(7) manual page.


   The initial access control list for display number n may be set by  the
   file  /etc/Xn.hosts,  where n is the display number of the server.  See
   Xserver(1) for details.

[HR][/HR]

I have not yet found a way to grant root access to the Xserver. Maybe
with xauth?

I don’t understand the manual. Apparently “xhost list” would give the
list, but:

cer@Telcontar:~> xauth list
Telcontar.valinor:0  MIT-MAGIC-COOKIE-1  771d792bd54a483c99ec42fcc81b660e
[fe80::221:85ff:fe16:2d0b]:0  MIT-MAGIC-COOKIE-1
771d792bd54a483c99ec42fcc81b660e
Telcontar/unix:0  MIT-MAGIC-COOKIE-1  771d792bd54a483c99ec42fcc81b660e
nimrodel/unix:10  MIT-MAGIC-COOKIE-1  9436c516928ffeef0d016756be88fd03
Telcontar/unix:11  MIT-MAGIC-COOKIE-1  bbb5c0ce60d974f1d2a11f8bd2a51223
Telcontar/unix:1  MIT-MAGIC-COOKIE-1  c4e3a8476e6c7b41bc8638e042c88232
Telcontar.valinor:1  MIT-MAGIC-COOKIE-1  c4e3a8476e6c7b41bc8638e042c88232
localhost:1  MIT-MAGIC-COOKIE-1  c4e3a8476e6c7b41bc8638e042c88232
localhost:0  MIT-MAGIC-COOKIE-1  9cb8f93edd64c10ae14ac72db8f82153

i don't see how to authorize a user.

I think you somehow have to pass that MIT-MAGIC-COOKIE token.
But I haven’t found out how, yet.

> And another thing:
> Explicitely setting the DISPLAY variable does work also with GNOME
> applications.
>
> Code:
> --------------------
> sudo DISPLAY=:0 gedit
> --------------------
>
> works here (after calling “xhost +” of course).

It works here without the DISPLAY part, after “xhost +”. That’s the
crucial part, not the display variable.

No. On my system (12.3 with default /etc/sudoers) both is needed, since sudo doesn’t pass the DISPLAY variable (no matter if you use ‘-i’ or not).

You could of course change that in /etc/sudoers. You could even tell sudo to set DISPLAY to a certain value, see the “env_file” option in the sudoers manpage.

But “xhost +root@localhost” does not.

Right, because it’s interpreted as a nis name. That’s what I wrote.

[wolfi323]

@robin_listas

On 2013-06-05 18:42, Jim Henderson wrote:
> On Wed, 05 Jun 2013 12:06:02 +0000, wolfi323 wrote:
>
>> So with “xhost +localhost” you would allow your user open windows from
>> localhost which is of course superfluous.
>
> Actually, it isn’t - I’ve used this in the past because the default is
> only the current user on the current host can open windows. Adding
> +localhost lets any user on the local machine open windows in the GUI.

It does not work here.

It doesn’t work here either.
Perhaps it worked that way in earlier versions…

[robin_listas]

On 2013-06-06 14:26, wolfi323 wrote:

>> “host or a user name” - it says so clearly.
> Well, not here on my 12.3 system:

It has changed. Probably was changed earlier but not the man page.

…

>> +]name The given name (the plus sign is optional) is ad
>>> Code:
>>> --------------------
>>> sudo DISPLAY=:0 gedit
>>> --------------------
>>>
>>> works here (after calling “xhost +” of course).
>>
>>
>> It works here without the DISPLAY part, after “xhost +”. That’s the
>> crucial part, not the display variable.

> No. On my system (12.3 with default /etc/sudoers) both is needed,
> since sudo doesn’t pass the DISPLAY variable (no matter if you use ‘-i’
> or not).

Remember that my sudoers is not the default one.

>> But “xhost +root@localhost” does not.
> Right, because it’s interpreted as a nis name. That’s what I wrote.

The doc for 12.1 is wrong, not my fault

–
Cheers / Saludos,

Carlos E. R.
(from oS 12.3 “Dartmouth” GM (rescate 1))

[wolfi323]

@robin_listas

> No. On my system (12.3 with default /etc/sudoers) both is needed,
> since sudo doesn’t pass the DISPLAY variable (no matter if you use ‘-i’
> or not).

Remember that my sudoers is not the default one.

Yes. I just wanted to point out that DISPLAY is not passed by default.

>> But “xhost +root@localhost” does not.

I found out the correct syntax:

xhost +local:root

[wolfi323]

And:

@wolfi323

NAMES
…
The local family specifies all the local connections at once. However,
the server interpreted address “si:localuser:username” can be used to
specify a single local user. (See the Xsecurity(7) manual page for more
details.)
…

So “xhost +local:” (and “xhost +local:root”) would grant access to all users on the local system and “xhost +si:localuser:root” only for root…

[hendersj]

On Thu, 06 Jun 2013 12:26:02 +0000, wolfi323 wrote:

> robin_listas;2562905 Wrote:
>> On 2013-06-05 18:42, Jim Henderson wrote:
>> > On Wed, 05 Jun 2013 12:06:02 +0000, wolfi323 wrote:
>> >
>> >> So with “xhost +localhost” you would allow your user open windows
>> from
>> >> localhost which is of course superfluous.
>> >
>> > Actually, it isn’t - I’ve used this in the past because the default
>> is
>> > only the current user on the current host can open windows. Adding
>> > +localhost lets any user on the local machine open windows in the
>> GUI.
>>
>> It does not work here.
>>
> It doesn’t work here either.
> Perhaps it worked that way in earlier versions…

That’s the way it worked the last time I used it. Since then, I’ve been
using gnomesu to launch apps that require root rights.

Jim

–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

[robin_listas]

On 2013-06-06 18:34, Jim Henderson wrote:
> On Thu, 06 Jun 2013 12:26:02 +0000, wolfi323 wrote:
>
>> robin_listas;2562905 Wrote:

>>> It does not work here.
>>>
>> It doesn’t work here either.
>> Perhaps it worked that way in earlier versions…
>
> That’s the way it worked the last time I used it. Since then, I’ve been
> using gnomesu to launch apps that require root rights.

Yes, but remember that the OP, and me, want to use sudo with the user password, not root’s password;
thus tools like gnomesu are no alternative.

–
Cheers / Saludos,

Carlos E. R.
(from oS 12.3 “Dartmouth” GM (rescate 1))

[robin_listas]

On 2013-06-06 16:36, wolfi323 wrote:
>
> robin_listas;2563042 Wrote:
>>
>>> No. On my system (12.3 with default /etc/sudoers) both is needed,
>>> since sudo doesn’t pass the DISPLAY variable (no matter if you use
>> ‘-i’
>>> or not).
>>
>> Remember that my sudoers is not the default one.
> Yes. I just wanted to point out that DISPLAY is not passed by default.
>
>>>> But “xhost +root@localhost” does not.
> I found out the correct syntax:
>
> Code:
> --------------------
> xhost +local:root
> --------------------

I’m not running now the system where I have sudoers configured, I can’t test it just now. But I
will, thanks.

–
Cheers / Saludos,

Carlos E. R.
(from oS 12.3 “Dartmouth” GM (rescate 1))