Subject: bin/6498: S/Key support on lock(1) is broken
To: None <gnats-bugs@gnats.netbsd.org>
From: ITOH Yasufumi <yasufu-i@is.aist-nara.ac.jp>
List: netbsd-bugs
Date: 11/25/1998 22:39:40
>Number: 6498
>Category: bin
>Synopsis: S/Key support on lock(1) is broken
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: bin-bug-people (Utility Bug People)
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Nov 25 05:50:00 1998
>Last-Modified:
>Originator: ITOH Yasufumi
>Organization:
Nara Institute of Science and Technology, Nara, Japan
>Release: 1.3I (Nov. 24, 1998)
>Environment:
System: NetBSD acha.my.domain 1.3H NetBSD 1.3H (UVM) #0: Tue Nov 17 11:19:55 JST 1998 itohy@myname.my.domain:/usr/src/sys/arch/x68k/compile/UVM x68k
>Description:
The lock(1) man page says it accepts S/Key authentication
but this doesn't work for non-root users.
>How-To-Repeat:
Try "lock -p" and type "s/key" at the "Key:" prompt.
% skeyinfo
Your next s/key 92 acha19262
% lock -p
lock: /dev/ttyp0 on acha.my.domain. timeout in 15 minutes
time now is Wed Nov 25 22:08:00 JST 1998
Key: [type "s/key" and return]Sorry, you have no s/key.
Key:
(Yes, the newline position is a little odd. :-)
>Fix:
This is caused by the "setuid(getuid());" near the beginning of
lock.c::main(), which prevents lock from opening /etc/skeykeys READ/WRITE.
The simplest solution is to remove the setuid(),
but more careful security consideration may be required.
>Audit-Trail:
>Unformatted: