Give root access to user's display + sudo problems
Linux - GeneralThis 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
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Give root access to user's display + sudo problems
Using debian, and I have debconf configured to use Qt to display questions or notices. However, since I can only run apt-get, dpkg, etc as root I always get
Code:
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
X is running on display :0 as far as the $DISPLAY variable can tell. My question is: how can I give root access to use it?
I thought of using sudo instead of having a terminal running as root. However, even after adding "ephracis ALL = (ALL) ALL" I keep getting "Sorry, try again" after typing the correct password. Is there some rehashing or such I don't know about? Have been using normal vi to edit /etc/sudoers but I also tried using visudo, nothing helped.
I don't think root can access user's display. Perhaps I'm wrong.
I think only the user logged in can launch the X server.
For the sudo issue, this is the setup:
Code:
root@silas:~# cat /etc/sudoers
# sudoers file.
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the sudoers man page for the details on how to write a sudoers file.
#
# Host alias specification
# User alias specification
# Cmnd alias specification
# Defaults specification
# Runas alias specification
# User privilege specification
root ALL=(ALL) ALL
# Uncomment to allow people in group wheel to run all commands
# %wheel ALL=(ALL) ALL
# Same thing without a password
%wheel ALL=(ALL) NOPASSWD: ALL <--- uncomment this line
# Samples
# %users ALL=/sbin/mount /cdrom,/sbin/umount /cdrom
# %users localhost=/sbin/shutdown -h now
Put All in the wheel group with no password, then add
your user to the group wheel by issuing as root, "vigr"
and you should be all set.
The problem with using the wheel group is that anyone who is in there has full root privileges so someone only needs to access one user account to have full access to the entire system.
Ephracis:
In KDE, you may be able to use kdesu to start x applications as root (it may be a SUSE tool, though). Another option is to use ssh, which allows root access to the x server on some systems. You can also use xhost +localhost to share the display with all local users.
root is able to access any display, as long as X server is set to allow it. Set root's DISPLAY variable, as it appears you have. Then the key is to enter "xhost +127.0.0.1" to a console. This will allow all local X connections, and should get rid of that "refused by server" message, and allow root to popup windows on the 0.0 session of X.
On some distros "xhost +localhost" or "xhost +IPADDRESS" don't work if you use "su -" to switch to root, but work fine if you just use "su". If you need to run X as root from other hosts, you can do "xhost +".
Quote:
Originally Posted by Chinaman
That's why we create good passwords...
I see. I guess all those systems that get cracked are not using strong passwords.
ksudo worked, as long as the program I was running was graphical, since it did not send any output to the terminal.
It seems that sudo cannot work with passwords enabled. It worked fine with the "NOPASSWD:" but with it I get "Sorry, try again" messages. This is bad since I don't want to make ephracis == root.
I added 127.0.0.1 and localhost to the accesslist with xhost, which didn't work. However, root could access X if I gave every host access to it with "xhost +". This is not good enough to me, since I don't want to disable the accesslist control.
if you only want to allow root instead of everyone, as root run:
Code:
/usr/X11R6/bin/xauth merge ~username/.Xauthority
Where username is the ordinary user who currently owns the display. I don't know why, but sometimes my .Xauthority file has its permissions changed by this. You may also have to run:
If you want to be logged on to the console as a normal user and using a GUI and run an X application as root then you want to use the sux utility. After looking around the Debian web site I found that the Debian etch release, which you are apparently using, is currently in testing. I checked the packages for this release and sux is available.
You use sux in a terminal window. Sux is just the su command for X. When you use this you need to define the DISPLAY environment variable once you have switched users. I just put this in my root account's $HOME/.bashrc file.
DISPLAY=":0.0"
I love it. I can be logged on at the console as a normal user and still run Ethereal or tcpdump or netstat -a or whatever needs privileges. You can be browsing the Internet as a normal user and still have privileged software running. This is helpful if you are getting instructions from an Internet site about doing some task that needs privileges. Keep in mind, though, that the privileged processes still share the same X display, so that could be a security issue. If you have things displayed on your console from an application running as root that shouldn't be shown to the Internet then you might not want to do this. However, I do this all the time. I'm not too concerned about a malicious web site or whatever copying the X display from my machine. On the other hand a few months ago I received several emails that contained strange gif files that mapped a piece of the video display. Clearly these emails could have copied the partial display to some remote site. Be careful and you should be okay.
This is what I typically do. Open a Konsole terminal window then enter the following commands to run Ethereal.
sux -
password:
ethereal 2>/dev/null &
This keeps the nasty X error messages off of your Konsole window and allows you to run more than one application as root. This also works great if you have other normal user accounts. You can sux - <user> and run X applications as that user. I use this to keep my business information in a different user account that never accesses the Internet. My Internet access account cannot see into the business account's home directory. I can log on to the business account using sux and run Kontact, Kmail, Koffice, and other applications.
I almost forgot. The su and sux commands are different than sudo. When you use sudo you enter your normal user account password. When you use su and sux you enter the password of the account that you are switching to.
Last edited by stress_junkie; 01-11-2006 at 06:30 PM.
I see. I guess all those systems that get cracked are not using strong passwords.
Let's not talk hypothetical, such as "all those systems that get cracked."
I have NEVER had a system cracked, and I use passwords that won't be
broken by some little script kiddie on the net. If you are using a password
that cannot be broken by a dictionary editor (I am), then with the default
install of Slackware, updated by the patches Pat releases, you should have
no worry about a cracker.
Give proof otherwise. I'm tired of people crying wolf with no substantiation.
The fact of the matter is that a default install of Slackware, without systems
running that aren't used and hardened, is quite secure.
I welcome all kiddies who want to try to break into ANY of my 6 Slackware
boxen. No one's done it yet, and where I live, it's tried often.
Let's not talk hypothetical, such as "all those systems that get cracked."
I have NEVER had a system cracked, and I use passwords that won't be
broken by some little script kiddie on the net. If you are using a password
that cannot be broken by a dictionary editor (I am), then with the default
install of Slackware, updated by the patches Pat releases, you should have
no worry about a cracker.
Give proof otherwise. I'm tired of people crying wolf with no substantiation.
The fact of the matter is that a default install of Slackware, without systems
running that aren't used and hardened, is quite secure.
I welcome all kiddies who want to try to break into ANY of my 6 Slackware
boxen. No one's done it yet, and where I live, it's tried often.
Just because you have not been affected by something does not mean that it cannot happen or won't happen. You may have lots of confidence in yourself and know these potential problems but others may not and thats why I have pointed out one of the potential risks of using the wheel group even if you have a strong password.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.