gets
Why this happens? This should work.

Are you sure the display number is 0?
Try with other numbers 0.1 0.2 0.3...

I suppose you are running X already.

It's a setting I've only seen on Slackware and I don't know how to change it in the Xorg.conf file. However, there's still a workaroung which is typing "xhost +" in a console before typing your command.

Yes, I am.

Yes, I am running. $USER returns user, currently running X. So, if user is running X, the command, i issued below should work.
xhost+ should not be used. Instead a magic cookie should be imported. But, I repeat, the $USER is already running X an has the privileges to run graphical programs on X.

If the answer to the question appears to be "xhost +" then the question was a very stupid one. Always. Doing so is right up there with simply removing the front door to your house because the doorbell needs new batteries. Never, ever do this on a machine that's connected to a network or has more than one user account.

Not using the dash argument to su should allow the process to change UID without ditching the variables that contain the authentication tokens and information about where the display is.

Try like this:
"unset XAUTHORITY ; export DISPLAY=:0.0 ; amarok"

There's a nice little shell program called sux that will do this job for you. Look for the debian version sux-1.0.1 (sux_1.0.1-3.2.tar.gz)

Then, if xhost + is Evil, what's the solution to launch graphical programs as root on a console under a normal user? It was possible on Mandriva and this was the only solution I found to do the same on a Slackware...

The magic solution on KDE session is:
once You type the password, it runs amarok even with root's KDe preferences and theme.

su - $USER -c "unset XAUTHORITY ; DISPLAY=:0.0 ; amarok"

ssh -Y user@localhost

BTW is there a reason to run amarok as root?
What's the gain? Latency?

He's not trying to run the application as root. He's trying to get root to start the program for the user and have the program belong to the user.

Did You mean:
root is trying to start an plication for a non-root user who's running X?

Like,
a phantom (non-X-running root) root launches windows across a users session?

sure I would like that, but there must be a way to authenticate to X as a valid user who has permissions to open windows?

I know my suggestion works because it it the method I use to display icons on a users desktop when usbstorage devices are connected to my system. Connecting devices triggers udev(or hotplug) events which are run as root. That makes it easy for root to start a process on the users desktop. But if the process belongs to root the user cannot control it. By starting the process as the user(using su - $USER), the user can control it.
You can use xauth to get the credentials of the user and apply them to the new process or transfer the credentials of root which is probably very bad. But unsetting XAUTHORITY is much easier and may be safer assuming the root account is safe - the user is already authenticated if he already has a DISPLAY so XAUTHORITY can be ignored.
Some programs may still not do all of what you want unless you discover and export extra environmental variables associated with the desktop being used.

So, as gnashley states, presuming all users have passwords, one could do that. Not that is bulletproof, but it's acceptable for a good reason.

Otherways, couldn't the user have own startup scripts?
Isn't there a way with hall / dbus? how des Bluetooth make it?
We all see that even PV puts HAL in Vanilla-slack.