Bug 11718 - 4_b1: No protocol specified sudo su - some_user in run level 5
Summary: 4_b1: No protocol specified sudo su - some_user in run level 5
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-21 10:00 CET by Bit Twister
Modified: 2016-01-10 04:07 CET (History)
1 user (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments

Description Bit Twister 2013-11-21 10:00:17 CET
Description of problem:

"No protocol specified" when running
     sudo su - some_user
in run level 5 (gui boot)

[bittwister@wb ~]$ sudo su - junk
[junk@wb ~]$ export DISPLAY=:0.0
[junk@wb ~]$ xterm
No protocol specified
Error: Can't open display: :0.0
[junk@wb ~]$ echo $DISPLAY
:0.0


sudo su - junk works in run level 3 (non-gui boot)


$  cat /etc/sysconfig/desktop
DISPLAYMANAGER=kdm
DESKTOP=KDE4

Version-Release number of selected component (if applicable):


How reproducible: Always


Steps to Reproduce:
1. create user junk
2. create /etc/sudoers.d/sudo_sys_owner with
Host_Alias    CSNETS = 192.168.1.0/24
User_Alias    FULLTIMERS = bittwister
Cmnd_Alias    SU = /usr/bin/su
FULLTIMERS    ALL = NOPASSWD: ALL

be sure to change Host_Alias and User_Alias to match your setup.

3. chmod 440 /etc/sudoers.d/sudo_sys_owner
4. boot system in runlevel 3
5. log into your normal user account
6. click up a terminal
7. sudo su - junk
8. export DISPLAY=:0.0
9. run some gui application, xterm, xeyes, kwrite, ....
10. Now boot system in run level 5
11. run steps 5 through 9


Temporary Workaround solution after sudo command run level 5:

export XAUTHORITY=~your_normal_loginid/.Xauthority

Example:
[bittwister@wb ~]$ sudo su - junk
$ export XAUTHORITY=~bittwister/.Xauthority
$ export DISPLAY=:0.0
$ xterm

Another workaround is change display manager to gdm and reboot system.
That assumes you have gdm installed. Example:

$  cat /etc/sysconfig/desktop
DISPLAYMANAGER=gdm
DESKTOP=KDE4



Reproducible: 

Steps to Reproduce:
Comment 1 David Walser 2013-11-22 19:09:27 CET
Why are you running sudo su?  Use sudo -s or sudo -i.
Comment 2 Bit Twister 2013-11-22 22:13:25 CET
(In reply to David Walser from comment #1)
> Why are you running sudo su?  

Because I want to click a desktop shortcut to magically log into ~browser, ~bank, ~creditcard, ... Linux accounts without having to enter a password.

There have been cracked websites which establishes a session link allowing the cracker/criminal to do whatever the user's privileges allow. That session link remains in memory until the user logs out of the system. Currently I have .bash_profile launch firefox, upon firefox exit launch an "at" script to remove directories/files and tar in a pristine setup. That way I know I am pretty safe.
Comment 3 Manuel Hiebel 2013-11-26 00:03:38 CET
isn't it https://bugs.mageia.org/show_bug.cgi?id=3782 ?
Comment 4 Manuel Hiebel 2013-11-26 00:04:43 CET
another https://bugs.mageia.org/show_bug.cgi?id=11184#c55
Comment 5 Bit Twister 2013-11-26 01:45:30 CET
(In reply to Manuel Hiebel from comment #3)
> isn't it https://bugs.mageia.org/show_bug.cgi?id=3782 ?
> another https://bugs.mageia.org/show_bug.cgi?id=11184#c55

I will agree there may be a common problem with XAUTHORITY not being set.
I will guess those may have the additional problem because DISPLAY is not being set. I have to manage exporting DISPLAY with a kluge in the profile start up scripts.

But, I do not know if their tools are launched with su xxx 
or the command sudo su xxx. I assume it is su xxx.
I know DISPLAY/XAUTHORITY problems can be solved in /usr/bin/drakconf and not fix my bug.

The only way I can get sudo su xxx to work in run level 3 an 5 is to change DISPLAYMANAGER=gdm in  /etc/sysconfig/desktop and install the gdm package.
Comment 6 David Walser 2014-01-28 16:38:10 CET
It is reproducible, but this sounds invalid.  sudo su is a strange thing to do.  I guess the purpose is to run something as this dummy user without needing to put in a password.  I would think using ssh keys and ssh to junk@localhost would be a better solution for that, as the X stuff would all be handled by ssh.  Granted you need to run sshd for that.  Anyway, sudo isn't designed for this use case, so the X stuff isn't getting handled, and the junk user isn't getting authorized for your display, which isn't a surprise.  You could also have your desktop icon "Run in a terminal" which would pop up a terminal, which would allow you type in the password if you just used su - junk -c firefox or whatever for your command.  I can't imagine that you do it often enough that typing in a password would be a big inconvenience.

If you really believe there is a problem with kdm here, I would recommend you report it upstream, but I would imagine they'll have the same response as me (but it never hurts to try).
Comment 7 Nic Baxter 2016-01-10 01:56:04 CET
Anything more to add for this report? Should it be closed?

CC: (none) => nic

Comment 8 Bit Twister 2016-01-10 04:07:44 CET
(In reply to Nic Baxter from comment #7)
> Anything more to add for this report? Should it be closed?

Still broke on Release 5. Working on Release 6. Sure, I'll close it.

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.