VV VV LL OOO CCCCC KK KK VV VV LL OO OO CC KK KK written by VV VV LL OO OO CC KK Michael K. Johnson VV VV LL OO OO CC KK KK for Linux Journal VVV LLLLLLLL OOO CCCCC KK KK This is vlock, the Linux _V_irtual Console locking program. It allows you to lock one or all of the sessions of your Linux console display. Usage is very simple; by default, vlock locks the single console you are on. The -a or --all flags cause it to lock the console completely, so that users cannot switch to another virtual console. If you are working on a shared Linux computer, and want to lock a console session as you left it, but want to allow other users to log onto other sessions, simply run vlock when you leave the computer. If you want to lock the console so that no one else can log onto any of the virtual consoles (perhaps because you have login sessions running on several other virtual consoles at the same time), you use the -a or --all flag to cause vlock to not allow any user to switch to any console without typing your password. WARNING: If you lock all the consoles, they will be *really* locked. Unless you have a serial terminal, or can log in remotely via a network to kill vlock, you *will not* be able to get back to your terminal session without entering the correct password. While I was developing this program, a few small bugs forced me to do *hard resets*. If you loose data because you have to reset your computer because of vlock -a, it is your own problem, not mine. I warned you. The root password will *always* be able to unlock any vlock session. If anyone else can log in as you, they can send a SIGKILL to vlock, which *will* kill it. If you wish to avoid this, you may make a vlock account, and make vlock setuid vlock, or you may make vlock setuid root. However, I do not guarantee that making vlock setuid is safe. DO THIS ONLY AT YOUR OWN RISK. I TAKE NO RESPONSIBILITY FOR THE CONSEQUENCES IF YOU MAKE vlock SETUID ROOT. The vlock binary can be installed wherever you like, with whatever name you like. However, it will always call itself vlock, even if you rename it. If you want to change that, use the source... "vlock -h" or "vlock --help" will get you a help message. If you have the "open" program, try doing `open vlock -a' to run vlock on a new VC. This will keep your current VC from getting obscured by silly password messages... *** Features: *** Currently, vlock doesn't have very many features. It locks the console, and now will even try to lock other sessions as well. I hope that non-VC sessions will be locked securely, but I don't know for sure. *** PAM: *** vlock supports PAM authentication with the USE_PAM compile-time flag. It will try to authenticate the user's password in a separate pass from root's password, instead of quietly trying the password as both the user and root. This is to let PAM do all the authentication, including asking for the password, itself. *** Shadow passwords: *** First of all, if your system supports PAM, use USE_PAM, not SHADOW_PWD. PAM is capable of supporting shadow passwords WITHOUT requiring that an application be setuid root or setgid shadow; it uses a special helper application to check passwords. On a shadow system with PAM, the only reason to make vlock setuid root is for the root password to be able to unlock a session; on a shadow system with a non-root application (like vlock normally is), PAM will only allow you to check your own password, not anyone else's. Compile with -DSHADOW_PWD, and make vlock setuid root or setgid shadow (however your shadow password setup is done). However, there are bugs in several flavors of the shadow library which make it impossible to make vlock secure on those systems when compiled with shadow. NOTICE: Except for shadow passwords, this program does not need to run with any setuid or setgid priviledges, and I do not guarantee that it is safe. I don't know of anything in particular that would make it unsafe, but I haven't tried to find anything either. In any case, whether running it setuid, setgid, or with no special permissions, I can take no responsibility for any damages caused by this program or your use of it. I give no warranty of merchantability or fitness for a particular purpose. For version 0.9, Marek Michalkiewicz rewrote the shadow password support correctly. He should know, since he maintains shadow for Linux. He says: Shadow support redone properly (I hope) - the program has to be installed setuid root, but it will drop privileges as soon as possible. It should be safe (insert standard disclaimers here). The use of setgid shadow is not recommended - ypserv may require that you connect from privileged port (to make NIS slightly less insecure), and you must be root for that. With ELF libc-5.x the problems with buggy shadow libraries are gone - no need to link with them at all :-) (because shadow passwords are now supported in the standard libc). The shadow-aware vlock works fine with non-shadow passwords too, so it's OK to always define SHADOW_PWD when creating distribution binaries (this will make the transition to shadow passwords easier - one less program to recompile). I also fixed a few bugs, cleaned up the code a bit, and made some enhancements. My changes are public domain. April 9, 1996 -- Marek Michalkiewicz *** Bugs fixed: *** Quits if the tty is closed (not applicable to VCs). Asks for password on non-PAM systems. March 12, 1998. Moved to new PAM conversationg function conventions. October 10, 1997. Shadow support was minimal. Fixed May 16, 1996. Used /dev/console instead of /dev/tty. Fixed May 16, 1996. Ctrl-Break was able to kill vlock. Fixed July 3, 1994. With vlock -a, after guessing the password wrong once, it was possible to switch VC's. Fixed July 3, 1994. Root was not allowed to lock his tty because I took my password reading program from GNU su, for which it is appropriate for root not to be asked to enter a password... This was fixed March 21, 1994. Message said to use Control-function key, not Alt-function key. This was fixed March 23, 1994. SIGQUIT could break out of vlock in some cases. This was fixed March 23, 1994. Please email me any comments you have about vlock: johnsonm@redhat.com I wrote this code as a demonstration of the VT ioctls for Linux Journal. Subscription information is available on the web at http://www.ssc.com/lj and via email through info@ssc.com