From owner-freebsd-security Thu Dec 7 6:30:25 2000 From owner-freebsd-security@FreeBSD.ORG Thu Dec 7 06:30:23 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from bsdie.rwsystems.net (bsdie.rwsystems.net [209.197.223.2]) by hub.freebsd.org (Postfix) with ESMTP id 35EE337B401 for ; Thu, 7 Dec 2000 06:30:23 -0800 (PST) Received: from bsdie.rwsystems.net([209.197.223.2]) (1466 bytes) by bsdie.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Thu, 7 Dec 2000 08:29:03 -0600 (CST) (Smail-3.2.0.111 2000-Feb-17 #1 built 2000-Jun-25) Date: Thu, 7 Dec 2000 08:29:03 -0600 (CST) From: James Wyatt To: Joerg Wunsch Cc: freebsd-security@freebsd.org Subject: Re: Please review a change to lock(1) In-Reply-To: <20001207115835.V4709@B7173150.DeutschePost.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Maybe you could see if it's PPID becomes 1 as init inherits it as an orphan from the dead parent process. I would *definately* syslog the error as a simple error *could* be an attempt to trick lock. Some programs deserve paranoia due to their use and level of users' blind trust. - Jy@ On Thu, 7 Dec 2000, J Wunsch wrote: > i think everybody's happy when seeing those dead processes running > around forever, eating up all CPU time -- since they are too stupid to > notice the tty they're trying to read from is gone. lock(1) is one of > those culprits, as i just noticed. You can easily prove this by > logging into a plain tty, starting "lock -np", and killing the shell > e. g. with SIGABRT (or SIGKILL to be sure). The shell is gone, but > lock is still there, trying to lock nothing now... [ ... wish more folks would trim posts ... ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message