From owner-freebsd-bugs@FreeBSD.ORG Thu Feb 16 11:20:11 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74EF716A420 for ; Thu, 16 Feb 2006 11:20:11 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51BCC43D53 for ; Thu, 16 Feb 2006 11:20:10 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k1GBKAgU027965 for ; Thu, 16 Feb 2006 11:20:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k1GBKArT027964; Thu, 16 Feb 2006 11:20:10 GMT (envelope-from gnats) Resent-Date: Thu, 16 Feb 2006 11:20:10 GMT Resent-Message-Id: <200602161120.k1GBKArT027964@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Andrew Hacking Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 312AD16A420 for ; Thu, 16 Feb 2006 11:13:00 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 010EB43D45 for ; Thu, 16 Feb 2006 11:13:00 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k1GBCxEg040805 for ; Thu, 16 Feb 2006 11:12:59 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k1GBCxXh040804; Thu, 16 Feb 2006 11:12:59 GMT (envelope-from nobody) Message-Id: <200602161112.k1GBCxXh040804@www.freebsd.org> Date: Thu, 16 Feb 2006 11:12:59 GMT From: Andrew Hacking To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: kern/93423: Applying devfs rulset fails X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2006 11:20:11 -0000 >Number: 93423 >Category: kern >Synopsis: Applying devfs rulset fails >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Feb 16 11:20:09 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Andrew Hacking >Release: 6.0-RELEASE-p4 >Organization: >Environment: FreeBSD home.inet 6.0-RELEASE-p4 FreeBSD 6.0-RELEASE-p4 #1: Wed Feb 15 10:50:20 EST 2006 root@home.inet:/usr/obj/usr/src/sys/DELL4100 i386 >Description: It is currently not possible (for me at least) to setup a secure jail by adding devfs rules. Also devfs commands can leave the system in a state where it is not possible to shutdown cleanly. On attempting to setup devfs for a jail, the following devfs command fails: # mount_devfs devfs /jail/foo/dev # devfs -m /jail/foo/dev rule -s 4 applyset devfs rule: ioctl DEVFSIO_SAPPLY: No such process [Note: rule-set doesn't get applied] Also, trying to apply rules manually hangs and never returns, leaving the process blocked in disk (D) wait state. Shutting down the system also never completes and requires a power cycle and (at least for me) required manual fsck of most file-systems on reboot. This could potentially be related to the problem described in: http://lists.freebsd.org/pipermail/freebsd-hackers/2006-January/015009.html My revision of /usr/src/sys/fs/devfs_rule.c is: $FreeBSD: src/sys/fs/devfs/devfs_rule.c,v 1.14.2.2 2005/09/26 14:36:52 phk Exp $ I will try revision listed in above email and report back.... >How-To-Repeat: # mkdir /tmp/foodev # mount_devfs devfs /tmp/foodev # devfs -m /tmp/foodev rule -s4 applyset devfs rule: ioctl DEVFSIO_SAPPLY: No such process [Note: rule-set doesn't get applied] Now try adding rules manually to trigger process hang: # devfs -m /tmp/foodev rule add hide # devfs -m /tmp/foodev rule add path null unhide .. etc ... >Fix: >Release-Note: >Audit-Trail: >Unformatted: