run as different user fails (wrong ownership of .Xauthority and /tmp/libgksu-xxx)

sorry, this is on an updated Intrepid i386 with
gksu 2.0.0-5ubuntu3
libgksu2-0 2.0.7-1ubuntu2

Confirming this. Trying to run an application as another (non-root) user

gksudo -u anotherusername

fails due to the way gksudo sets permissions

* on the file

-rw------- 1 originaluser originaluser 123 2009-03-05 01:44 .Xauthority

* and on the directory:

drwx------ 2 originaluser originaluser 4096 2009-03-05 01:30 libgksu-abcde

The description of this package says:

"...It is useful to menu items or other graphical programs that need to ask a user's password to run another program as another user..."

So it should be reasonable to expect that this package would work to execute a program as a another "non root user".

This may help tracking down this bug:

The ownership is set correctly when using the the "su" method (by calling the "gksu" binary directly instead of of through the "gksudo" symlink AND with the -w option).

This fails:

$ gksudo -u firefoxuser firefox
No protocol specifiedNo protocol specified
Error: cannot open display: :0.0

The following works inspite of the warnings, however the password of the target user is allways required and you can not make use of the NOPASSWORD option in the sudoers file with that.

$ gksu -w -u firefoxuser firefox

(firefox:3439): GnomeUI-WARNING **: While connecting to session manager:
None of the authentication protocols specified are supported.

(firefox:3439): GnomeUI-WARNING **: While connecting to session manager:
None of the authentication protocols specified are supported.

(firefox:3439): GnomeUI-WARNING **: While connecting to session manager:
None of the authentication protocols specified are supported.

---

It's quite a security shame that ubuntu ships without fully working "running as different user" mechanisms for so long.

(way off topic...)

> It's quite a security shame that ubuntu ships without fully working "running as different user" mechanisms for so long.

 I wouldn't give un-trusted programs access to my X display. X isn't secure like that! When I run p2p filesharing programs (complex and crash-prone programs written in C, specifically designed to connect to many untrusted peers... What could possibly be wrong with that?) I run them as a different user (that doesn't have sudo privs, among other things), displaying on a Xvnc. I even have a startxvnc.sh script that starts xvnc, starts fluxbox on it, starts mrxvt, and injects commands into the mrxvt (via its --useFifo option), so it's like I interactively started things from the shell in the mrxvt. Or, most usefully, from an interactive gdb in the shell in the mrxvt, so I can thread apply all bt full when the program eventually crashes.

 I've thought about using apparmor to restrict p2p programs, but they're written to be able to upgrade themselves, so they need write access to their own binaries, and of course access to an X display. (using Xvnc makes it detachable/re-attachable after restarting my desktop, like screen(1) is for programs in a terminal window.)

Thank you for the hints Peter. Which vnc packages did you install?

So regading the fix for running apps as different user, it should probably make use of xnest or Xephyr?

Fedora's "sandbox -X" seems to be made for this.

The following wikipage contains valuable information about working with different user accounts
https://wiki.ubuntu.com/MultiUserManagement

Any progress on this bug?

I made a small program that solves this problem.

@ Markus: Script works very well! Thanks!

Still present with xenial