LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices


Reply
  Search this Thread
Old 12-07-2008, 07:15 AM   #16
tredegar
LQ 5k Club
 
Registered: May 2003
Location: London, UK
Distribution: Fedora38
Posts: 6,147

Rep: Reputation: 435Reputation: 435Reputation: 435Reputation: 435Reputation: 435

@browny_amiga,
Off-topic, but,
Quote:
One of the biggest bothers for me is that when I go
su -
on the CLI that then I cannot start GUI tools anymore, "cannot open display", without giving Root permission.
What sense does that make? None!
You need to use kdesu GUItoolname (for KDE) or gtksu GUItoolname (if using Gnome).
 
Old 12-07-2008, 10:10 AM   #17
David the H.
Bash Guru
 
Registered: Jun 2004
Location: Osaka, Japan
Distribution: Arch + Xfce
Posts: 6,852

Rep: Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037
Quote:
Originally Posted by browny_amiga View Post
I have not tried the last post before this one, but xhost + so far has given me hard trouble. It always tells me "cannot open display". xhost is not a graphical application, it does not use or open a display, it sets permissions. Is there a bug in there? Why does it tell me "cannot open display" when I use it with "give permission to all"?
You may be having your remote connection refused. Many distros also set the xserver to ignore tcp connections by default. This has to be re-enabled before remote displays will work. It may vary between distros, but at the very least you may have to remove the "--nolisten tcp" line from /etc/X11/xinit/xserverrc or a similar file to allow it access.

(note, the following contains details of my experience that may or may not be useful to you, but could help some people out.)

I know this because I recently had a b**** of a time getting desktop sharing to work between my two systems. On my system I discovered that in addition to modifying xserverrc that I also had to change my /etc/kde3/kdm/kdmrc to comment out the line "ServerArgsLocal=-nolisten tcp". So far so good.

But this is where it got difficult. It seems that the freedesktop standard (I believe) doesn't look at the /etc version of kdmrc directly, but copies it on startup to /var/run for actual use from there. Unfortunately there was (still is?) some bug in the genkdmconf program that does the copying that forced it to alway generate a new default kdmrc instead of copying my modified one. I tried all sorts of things to get around it, but I finally had to resort to using brute force. I found the line in my /etc/init.d/kdm file that runs genkdmconf, and then simply added a line right after it to manually copy the correct kdmrc after genkdmconf did it's work. I know it's a dirty hack, but it did the job.


PS: note that when you do get x sharing working that it's advisable to limit your xhost permissions to only the systems you want to connect. Even better would be to set up a proper xauthority handshake, as described here.
 
Old 12-09-2008, 03:02 PM   #18
tlhonmey
LQ Newbie
 
Registered: Nov 2008
Posts: 18

Rep: Reputation: 5
That's because I accidentally left out a bit. Try it like this:

Code:
root@laptop:~# xmessage test
Error: Can't open display:
root@laptop:~# xhost +
xhost:  unable to open display ""
root@laptop:~# export DISPLAY=:0.0
root@laptop:~# su -c "xhost +" testuser
access control disabled, clients can connect from any host
root@laptop:~# xmessage test     
root@laptop:~# su -c "xhost +" testuser
access control enabled, only authorized clients can connect
root@laptop:~# exit
xit
Only the user who owns the display has permission to alter xhost access control. Hence the error messages. As root, however, you can run xhost as the user that owns the display, and so make it work. (that's the su -c command) Hopefully this works this time. Don't forget to set which display you wish to alter.

Last edited by tlhonmey; 12-09-2008 at 03:09 PM.
 
Old 12-11-2008, 03:50 PM   #19
brood1
LQ Newbie
 
Registered: Dec 2008
Posts: 8

Rep: Reputation: 0
Well another way to do things would be to create your own client that is installed on the machine that listens on a port via TCP. It can receive messages and display them if necessary.


Just a thought.
 
Old 12-26-2008, 08:09 PM   #20
browny_amiga
Member
 
Registered: Dec 2001
Location: /mnt/UNV/Mlkway/Earth/USA/California/Silicon Valley
Distribution: Kubuntu, Debian Buster Stable, Windoze 7
Posts: 684

Original Poster
Rep: Reputation: 56
Quote:
Originally Posted by tredegar View Post
@browny_amiga,
Off-topic, but,

You need to use kdesu GUItoolname (for KDE) or gtksu GUItoolname (if using Gnome).
Thanks for that, but I already knew that. Unfortunately, it still does not make sense that root it barred from using any X session.
 
Old 12-26-2008, 08:13 PM   #21
browny_amiga
Member
 
Registered: Dec 2001
Location: /mnt/UNV/Mlkway/Earth/USA/California/Silicon Valley
Distribution: Kubuntu, Debian Buster Stable, Windoze 7
Posts: 684

Original Poster
Rep: Reputation: 56
This has to be re-enabled before remote displays will work. It may vary between distros, but at the very least you may have to remove the "--nolisten tcp" line from /etc/X11/xinit/xserverrc or a similar file to allow it access.

PS: note that when you do get x sharing working that it's advisable to limit your xhost permissions to only the systems you want to connect. Even better would be to set up a proper xauthority handshake, as described here.[/QUOTE]

We are all talking about (well at least I am) local access here, not connecting from another machine. I am sitting at the machine and want access to it and cannot get it with root. Switching to root with su - and then getting blocked from using the session for any X program. xhost + should at least work in this context. It is a program to give access (local to remote or local to local) not require access to a screen to run itself. (how can you ever give access then, when you need a key to use the key to unlook a lock?)

Xserver sharing in any case is a tough cookie. Does it really need to be THAT complicated and cryptic?
 
Old 12-26-2008, 08:18 PM   #22
browny_amiga
Member
 
Registered: Dec 2001
Location: /mnt/UNV/Mlkway/Earth/USA/California/Silicon Valley
Distribution: Kubuntu, Debian Buster Stable, Windoze 7
Posts: 684

Original Poster
Rep: Reputation: 56
Quote:
Originally Posted by tlhonmey View Post
That's because I accidentally left out a bit. Try it like this:

Code:
root@laptop:~# xmessage test
Error: Can't open display:
root@laptop:~# xhost +
xhost:  unable to open display ""
root@laptop:~# export DISPLAY=:0.0
root@laptop:~# su -c "xhost +" testuser
access control disabled, clients can connect from any host
root@laptop:~# xmessage test     
root@laptop:~# su -c "xhost +" testuser
access control enabled, only authorized clients can connect
root@laptop:~# exit
xit
Only the user who owns the display has permission to alter xhost access control. Hence the error messages. As root, however, you can run xhost as the user that owns the display, and so make it work. (that's the su -c command) Hopefully this works this time. Don't forget to set which display you wish to alter.
Thanks for the elaboration. But heck, it gets worse, now not even root has rights to give permission. Any permission MUST be available to root. This affair as it is right now is as absurd as the kernel not be able to access the display or some other aspect of the system. How the heck are you supposed to administrate a system, if you cannot do it with code running with root. I definitely have to find a way that you can enable root as superuser for all X sessions, even permission giving.

Strange, very strange ;-)
 
Old 12-26-2008, 08:42 PM   #23
browny_amiga
Member
 
Registered: Dec 2001
Location: /mnt/UNV/Mlkway/Earth/USA/California/Silicon Valley
Distribution: Kubuntu, Debian Buster Stable, Windoze 7
Posts: 684

Original Poster
Rep: Reputation: 56
Lightbulb [solution]

I found a solution that will work, it is a little unwieldy (you have to add it to every users .bashrc) but it seems to work:

add this line to a users .bashrc:

xhost +local:root

this gives the user root access to the users xsession.

in the root .bashrc you then have to add

export DISPLAY=:0.0

because without this, it will still fail because root does not seem to be on the same xscreen as the user ;-) *grin*

I think the Xserver could benefit from a thorough total redesign. It is very old and many structures don't fit the nowadays requirements very much anymore. And that comment is not just about permissions.
 
Old 04-13-2011, 11:56 PM   #24
m33600
LQ Newbie
 
Registered: Apr 2009
Location: sap paulo brazil
Distribution: debian, biglinux, ubuntu, puppy, eeebuntu, crunchbang, opensolaris
Posts: 10
Blog Entries: 1

Rep: Reputation: 0
osd_cat allways served me

Install osd_cat on target machines.
evoke it remotely, via ssh

I saw a Film in youtube. A Fire alarm that not only osd's te message but turn the cube...


http://www.youtube.com/watch?v=5MjDENKVuVg
 
Old 04-14-2011, 01:39 PM   #25
arizonagroovejet
Senior Member
 
Registered: Jun 2005
Location: England
Distribution: openSUSE, Fedora, CentOS
Posts: 1,094

Rep: Reputation: 198Reputation: 198
Quote:
Originally Posted by m33600 View Post
Install osd_cat on target machines.
evoke it remotely, via ssh

I saw a Film in youtube. A Fire alarm that not only osd's te message but turn the cube...


http://www.youtube.com/watch?v=5MjDENKVuVg
Hmmmm, but will that actually do what the OP wants? It looks like the script is running as the user that is logged in and the crux of the OP's probably is to being able to run the command as root.

The OP probably isn't paying attention any more, but in case they are and since the thread has aleady been revived, I think this is the, at least a, solution which doesn't involve adding anything to anyone's .bashrc

Code:
export DISPLAY=:0.0;
export  XAUTHORITY=$(ps h $(pidof X) | awk '{print $11}');
notify-send -t 604800000 -u critical "Hey you." "Very important message here"

If run as root that should put up a notification that the person who is logged in to the machine with an X session can see. It is taken from a script I use in a production environment. I assumes that the user's xauthority file is somewhere that root can access it, rather than in say an NFS mounted home directory with root squash applied.
 
Old 04-14-2011, 10:51 PM   #26
hunter121
LQ Newbie
 
Registered: Apr 2011
Posts: 1

Rep: Reputation: 0
if you wish a simple workaround, and you have root privileges on the machine in question, then it's pretty easy.
 
0 members found this post helpful.
Old 11-08-2011, 04:36 AM   #27
felix the cat
LQ Newbie
 
Registered: Nov 2011
Posts: 1

Rep: Reputation: Disabled
all_notify_send.sh

I did it with this script:

Code:
#!/bin/sh
export DISPLAY=:0.0
title=$1
text=$2
timeout=$3

pids=`pidof notification-daemon`
#echo $pids

if [ -z "$title" ]; then
        echo You need to give me a title >&2
        exit 1
fi
if [ -z "$text" ]; then
        text=$title
fi
if [ -z "$timeout" ]; then
        timeout=60000
fi

for pid in $pids; do
        # find DBUS session bus for this session
        DBUS_SESSION_BUS_ADDRESS=`grep -z DBUS_SESSION_BUS_ADDRESS \
                /proc/$pid/environ | sed -e 's/DBUS_SESSION_BUS_ADDRESS=//'`
        UNAME=`grep -z USERNAME \
                /proc/$pid/environ | sed -e 's/USERNAME=//'`
        DISP=`grep -z DISPLAY \
                /proc/$pid/environ | sed -e 's/DISPLAY=//'`
        XAUTH=`grep -z XAUTHORITY \
                /proc/$pid/environ | sed -e 's/XAUTHORITY=//'`
#        echo $UNAME $DBUS_SESSION_BUS_ADDRESS $DISP $XAUTH
        # use it
        DISPLAY=$DISP \
	DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS \
	XAUTHORITY=$XAUTH \
        su $UNAME -c "notify-send -u critical -t $timeout '$title' '$text'"
done
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Emergency : accidently deleted my user directory Vassos Linux - Newbie 4 11-20-2007 05:33 PM
how to show message to user denied to print I_like_TUX Linux - Newbie 3 10-19-2007 06:16 PM
POP-UP ERROR MESSAGE in RHWS4.0 jayfoo Linux - Software 0 09-27-2005 01:36 PM
Error message pop to the screen ust Linux - Distributions 3 04-13-2005 10:12 PM
Message Pop Up App netkepala Linux - Software 8 04-11-2004 08:38 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - General

All times are GMT -5. The time now is 03:09 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration