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

Thanks..

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

That's why we create good passwords...

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

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.

Any suggestions?

if you only want to allow root instead of everyone, as root run:

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.

http://packages.debian.org/testing/admin/

It is also available for the stable sarge release.

http://packages.debian.org/stable/admin/

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.

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.

Perhaps this discussion belongs in a different place...