Home | News | Download | Packages | Forum | Wiki | Github

[solved] Lock console after startx


#1

Hi!

Is there a way to automatically lock the console after starting X manually with startx? All I can think of is logging in to another tty and use vlock -a, but is there a better way? I’ve been playing around with putting vlock in .xinitrc or in a wrapper script, with no success and haven’t found anything useful searching the web.


Slim DM won't work
(Masato the Empty) #2

vlock is for locking the console; I don’t think it will work with X. It tries to detect the console it’s running from. If you run it in an xterm, it will lock the pts which that xterm is running but will be unable to lock the entire console screen.

You’ll need one of the X lock programs, probably one of the standalones like xlockmore or slock. Though I use lightlocker with lightdm, I always liked slock because it blanks the screen and never gives you a prompt (making the system look dead/unresponsive).

well it used to :frowning: now it has a feature (or antifeature if you will) to change colors when you start typing. only way to disable it is to change the make config (config.mk) and rebuild…

There’s an option to disable VT switching as well, so the system is truly locked.

xlock (xlockmore) has a lot more options (including screensaver options…) It can also disable VT switching.

Those can be put into your xinitrc (it works)


#3

Thanks @masato! Sometimes it’s hard to find the answer if you don’t really know the question :slight_smile:
What I was trying to accomplish was locking the VT in which startx was executed right after the command was executed, leaving the other VT’s alone.

Funny thing about xlock: the man page lists the option -vtlock, but when used it reports “bad command line option”. That’s what I would have preferred.

The slock man page says VT switching should be disabled in xorg.conf via

Section "ServerFlags"
             Option "DontVTSwitch" "True"
             Option "DontZap"      "True"
EndSection

Didn’t know these options before. So it’s irrelevant which locker you use, but I think I’ll take slock for now, thanks again for the tip to disable the color changing! :slight_smile:


(Masato the Empty) #4

You’re right. I don’t know what I was looking at… That’ll probably do it for xlock too.

xlock man page… not that it’s inaccurate in all builds, but it looks like the feature was disabled a long time ago. The vtlock code is still in the source, but the files haven’t been touched since 2007. It’s always been buried in an #ifdef, so it’s just disabled by default (there still seems to be a configure option to turn it on).

It’s reportedly a big security hole, though I don’t know the nature of that.

Come to think of it, it is a very dangerous thing. Additionally, I think adding those to your serverflags is too broad a brush; it probably means that you can never switch VTs once in X (unrelated to whether the screen is locked). So you should be cautious at least…


#5

That’s correct, just tested it. I’d prefer a scenario where the VT locks right after startx (if that’s possible) or alternatively when X is locked the VTs are locked, too, because I don’t want to use a login manager (it’s an old machine on which I use X only rarely). But if I do something stupid and lock myself out I still have network access (that is if I don’t break that too) :wink:


(Masato the Empty) #6

You know, I think I might have misunderstood what you were getting at from the beginning.

Was it important that the X session be locked right away, or was it only that the VT you used to launch it get locked (and you could lock the X session whenever you walked away and not have to worry about that VT still having an open session)

If that’s the case, you’re gonna love this (and maybe facepalm a little…)
# startx & vlock
aliasing that to startx works just fine.

EDIT: even more interesting is what happens when you do startx & vlock -a
It keeps you from automatically switching to the X VT. Xorg still fires up in the background AFAICT. It may be a timing thing, but I doubt X can fire up faster than vlock can lock you to the VT…


#7

Yes! That’s exactly what I was looking for! :slight_smile: And also that’s what I meant with looking for an answer when you don’t really know how to phrase the question. But there were quite some new insights on the way. So thanks for taking the time and trying to understand!

And to be honest a little bit facepalming is appropriate because I tried some combinations of startx and vlock before my initial post, but when I switched back to the VT in which I started X I didn’t see vlock’s password prompt. So I switched back to X thinking it didn’t work. Trying your line now I got the same result, but then I pressed a key (i.e. return) and realized the VT was locked indeed, the prompt just doesn’t show at first!


#8

This works for me, and you don’t need to edit any config files.

startx -- vt$(tty | sed -E 's|/dev/tty([0-9]+)|\1|g')

#9

Thank you @volleyper. That’s quite an interesting approach :slight_smile: .


(Stefan Mühlinghaus) #10

For me it is usually enough to just start X via exec startx. This does not prevent someone from switching back to TTY1 and killing your X server but afterwards they will be returned to the login prompt and cannot do anything else.


#11

I think you made a typo: it’s vlock (not vtlock) …

startx & vlock (aliasing that to startx works just fine on my computer! thanks @masato)


(Masato the Empty) #12

fixed, merci


#13

Once again thanks for all the info. It’s quite intriguing how such a simple task can be accomplished by a variety of different ways. :slight_smile:


(Xlaits Xavier) #14

Probably necroposting, and I’m sorry if I am, but I think this should be added to the wiki somewhere.