View previous topic :: View next topic |
Author |
Message |
The Doctor Moderator
Joined: 27 Jul 2010 Posts: 2678
|
Posted: Sat Jan 19, 2013 3:57 am Post subject: Command line login to X |
|
|
While login managers have their place, they do require running X as root, and hang out in the background. For more simple setups, it be convenient to have a lighter way to startx. This is particularly true if you are running openbox or similar which does not use the features of the login manager anyway.
This method assumes a bash shell.
To begin, one could simply edit the bashrc file to start X, but this is problematic. For everyday use, X is fine, but what about when (not if) X breaks? Switching to a console and using root might be an option unless the keyboard is dead as well. Also, an SSH login should not trigger X.
We can check /proc/cmdline to see if nox was entered as the boot parameter, then check the $DISPLAY variable and finally check the SSH status.
The result is something like this:
Code: | if [ "$(echo $DISPLAY | wc -w)" -eq "0" -a "$(cat /proc/cmdline | grep nox | wc -l) " -eq "0" ]; then
if [ -n $SSH_CONNECTION ]; then
exec startx
fi
fi |
This should simply be added to the end of the .bashrc file in your home directory.
ISSUES
The above script does not prevent an attacker from using ctr+alt+F1 to return to your shell and use ctr+c to kill X. To prevent that. It should be possible to replace the exec starx line with Code: | exec nohup startx > /dev/null 2&>1 &
disown
exit | This will startx as your user and then log your user out of the session without killing X. Alternatively, vlock can be used. In that case, exec startx should be replaced by: Code: | exec nohup startx > /dev/null 2&>1 &
vlock |
Both methods work fine when I tested them. I prefer the vlock solution as it simply requires entering your password, instead of username and password, to recover access to the TTY session.
I hope someone else finds this useful. Please, enter any comments/criticism of this method.
EDIT: After thought: shutdown and reboot can be achieved using sudo with NOPASSWD options. Implantation will very by WM _________________ First things first, but not necessarily in that order.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
Back to top |
|
|
PaulBredbury Watchman
Joined: 14 Jul 2005 Posts: 7310
|
Posted: Sat Jan 19, 2013 11:30 am Post subject: |
|
|
I use:
Code: | alias x='setsid /usr/bin/startx -- -nolisten tcp &> ~/.xorg.log & logout' |
From previous discussion.
Dunno why you want nohup & disown |
|
Back to top |
|
|
Ottre Tux's lil' helper
Joined: 23 Dec 2012 Posts: 129
|
Posted: Sat Jan 19, 2013 12:11 pm Post subject: Re: Command line login to X |
|
|
The Doctor wrote: | and finally check the SSH status.
Code: |
if [ -n $SSH_CONNECTION ]; then
|
|
What about serial console logins? A more robust check would be:
Code: |
if [[ $(tty) =~ /dev/tty[1-6] ]]; then
|
|
|
Back to top |
|
|
The Doctor Moderator
Joined: 27 Jul 2010 Posts: 2678
|
Posted: Sun Jan 20, 2013 3:47 am Post subject: |
|
|
PaulBredbury wrote: | Dunno why you want nohup & disown |
Maybe I am misunderstanding the nohup command. As I understand it, it keeps the process running with the same priority as a foreground task while otherwise it have reduced priority and therefore run slower.
The disown is so the process is not killed by a logout on the terminal. Thanks for the link to the Arch forums. That one did not surface in my Google search.
Ottre wrote: | What about serial console logins? A more robust check would be: Code: | if [[ $(tty) =~ /dev/tty[1-6] ]]; then |
| You are right! That is a much better check.
EDIT:
two more links that provide information, found vai the Arch thread:
[/url]http://en.gentoo-wiki.com/wiki/Non_Root_Xorg-Server[url]
http://www.gentoo-wiki.info/TIP_Fix_The_Login_Security_Hole
Looks like there is more on this that I realized originally started this thread or when I tried to do this myself. Oh well. _________________ First things first, but not necessarily in that order.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
Back to top |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Sun Jan 20, 2013 10:26 am Post subject: |
|
|
I just want to know why you find that an issue ?
If your X is run under user "that" and someone ctrl+alt+f1 to stop X, he will now have a console log as "that". So what ? he could have just open a new console in X and have the same.
If your X is run under a user because you don't need a login manager, how an attacker that is not "root" or "that" exist ? If you have more than one user, i suppose you would have use a login manager no ? |
|
Back to top |
|
|
PaulBredbury Watchman
Joined: 14 Jul 2005 Posts: 7310
|
Posted: Sun Jan 20, 2013 10:43 am Post subject: |
|
|
The Doctor wrote: | reduced priority |
What documentation gives you that impression?
krinn wrote: | he could have just open a new console in X |
Not if X is locked by a screensaver such as xscreensaver or i3lock. |
|
Back to top |
|
|
|