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: