1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
|
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 <marekm@i17linuxb.ists.pwr.wroc.pl>
*** 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
|
