Using telinit to switch runlevels leaves root logged on

[Ned Slider]

I have a question about using telinit to switch runlevels.

When I want to temporarily switch out of the gui, from my account, I su to root and "telinit 3". Then, when I've finished and want to switch back to the gui I su to root and "telinit 5". Trouble is, the last session (on tty 1) is left logged on as me and SUed to root.

Obviously this isn't good for security reasons - am I missing something here?

Ned

[markkuk]

Use "sudo", then the root environment is used only for a single command (e.g. telinit).

[jimmybgood]

I have a question about using telinit to switch runlevels.

When I want to temporarily switch out of the gui, from my account, I su to root and "telinit 3". Then, when I've finished and want to switch back to the gui I su to root and "telinit 5". Trouble is, the last session (on tty 1) is left logged on as me and SUed to root.

Obviously this isn't good for security reasons - am I missing something here?

Ned

Maybe, I'm missing something here. Can't you just go to tty1 (<Ctrl><Alt><F1>) and log out? And I guess I don't understand why you're using telinit anyway. If you want to get out of the gui, why not just go to tty1, do whatever you want to do and leave the gui running (but invisible) on tty7. When you want to get back to the gui use <Ctrl><Alt><F7>

[Ned Slider]

I wanted to quit the gui completely and restart X and kde, that's why I used telinit. I know there are other ways I could achieve this (as with most things in linux).

I just thought it somewhat of a security risk. When you telinit 5 -> 3 you are not left logged in, but when you telinit 3 ->5 as root, you are!

It was the fact that root (su) was left active when I didn't expect it that surprised me. If I had known that was the case of course I could switch back to the session and log out.

Ned

[jimmybgood]

Well, if no one objects I'll try an explanation. All telinit does is run a set of scripts to start and stop services. Usually the only big difference between run levels 3 and 5 is the display manager. In fact on my system, there is _no_ difference between 3 and 5. To restart my display manager, I go to tty1, log in and run "/etc/init.d/xdm restart". But I only do that if I'm changing something in my X configuration. To reset something like kde, I just zap my X session with <Ctrl><Alt><Bksp>.

Now when you login at your terminal in X and stop the display manager with "telinit 3", the terminal you are logged in on is a subprocess of the display manager. So it is killed along with it and you are logged out. When you are at the tty1 console and start your display manager with "telinit 5", the getty that runs tty1 is not affected, so you stay logged in.

I agree that leaving tty1 logged in as root is a security risk, but the only significant concern is if someone has physical access to your keyboard and can hit the <Ctrl><Alt><F1> keys. I suppose it would be possible to have scripts that reset the gettys when entering run level 5. I know traditionalists might find that annoying behavior, because they expect the console to remain active, but it might be a good idea to protect the unsuspecting, who now are probably the majority of Linux users.

[jimmybgood]

I'm just going to toss this out and see what people think. It might be a good idea, especially in distros that appeal to the less experienced Linux users, because of the security concerns mentioned above.

The exact names and directories are for Debian Sid and are likely different for different distros. Create a file with owned by root and with permissions 755 in /etc/init.d named, killgetties:

#!/bin/sh
killall getty
exit 0

then link to it from /etc/rc5.d

ln -s ../init.d/rc5.d/killgetties S99killgetties

I don't even know if it will work, but it's a thought!?

[Provicemo]

When I want X as closed as possible, this is what I do:
I restart X, ( Ctrl + Alt + Backspace)
Since I use gdm I have to stop that, so i switch to tty1 (Crtl + Alt + F1), then kill gdm (killall -9 gdm)
Then I can do what I need to do, usually modprobe -r nvida; modprobe nvidia.

[Ned Slider]

Thanks for your thoughts guys - and thanks Jimmybgood for your excellent explanation above.

Interesting stuff, and yet again I've learned something new with linux today

Ned