Talk:TIP Fix The Login Security Hole
From Gentoo Linux Wiki
Is it really possible to start the X-server as user just by using "startx"? I tried, but because of the suid-bit Xorg always starts as root. Removing suid-bit doesn't work.
Bye smurfer...
Contents |
[edit] Erm... *Removes foot from mouth/keyboard... thing*
Yeah, making this article public was kindof premature... You're right, startx does start X as root, even when run by qingy... I'm putting the Under Development Tag back on until I find out what other changes I made before... I could kick myself for not saving my configs when I re-installed last.
[edit]
Ah, I see, but nice to read that you got it working with some other changes. Looking forward for the tip to finish :-)
[edit] black screen when using quinqy
WARNING: this don't worked by me, I got a black screen and nothing more when I try to change current VT THIS TIP IS NOT SHURE YET
[edit] another solution
put the following line in your .zshrc (should also work with bash; you probably won't need the disown there)
alias onlyx="nohup startx &; disown; exit"
then do onlyx instead of startx; it will start x and then log off. if you are used to typing startx and aware of the consequences, you can also replace onlyx with startx (use =startx in zsh or `which -p ping` in bash to call startx without that side effect, then)
p.s.: i would have incorporated this comment into the article itself if it was not still under development; please move it there when unlockin!
[edit] re: another solution
This article's been locked for too long, and it's got some problems, I'm going to remove the notice and add my two cents.
Note that "another solution" was posted 12:01, 1 October 2006 86.59.50.121
--Superfake 01:57, 27 January 2007 (UTC)
[edit] Improvements to fix using screen
Using screen is a nice solution but the suggested method is rather cumbersome, requiring the user to switch back to screen and then issue commands manually. Instead, create a new screen configuration file, called say .screenrc.X with the commands:
screen startx lockscreen
Then to start X from the command line we can simply use:
screen -c .screenrc.X
However, I recommend the following bash script which also works from inside an already running instance of Screen:
#!/bin/sh
# Check if we are running from an existing screen session:
if [[ ${#STY} == 0 ]]; then
# No, start a Screen session with the .screenrc.X configuration"
exec screen -c .screenrc.X
else
# Yes, lock this Screen session then go to startx
screen -S "$STY" -X lockscreen
exec startx
fi
This will start X but the original terminal will be locked and require a password. The screen session is still detached, just as in the originally described fix (only an unlocked terminal can be used to access it).
If you log out of X, you will need to enter your password.
A few notes on the robustness of this fix. I've tested this script quite by running it with various arrangements of detached, attached and dead Screen sessions. The console terminal used to run the script locks in every instance. (There is one rather far-fetched caveat. Screen does not normally allow you to run nested sessions: running "screen" from "screen" just creates a new window within the same session. This is fine. But this behaviour can be overridden with "screen -m". Users should be wary of starting X from such nested sessions, as the console can remain vulnerable to Ctrl-a commands. Either avoid running X from nested screen sessions, or detach the sessions first.). Obviously, leaving other virtual terminals unlocked is another bad idea, regardless of whether they are connected to any screen sessions.
Are people happy for me to update the fix with these suggestions?
Rob 09:56, 19 September 2007 (UTC)
