From owner-freebsd-fs@FreeBSD.ORG Sun Feb 17 09:52:31 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BCC116A41B for ; Sun, 17 Feb 2008 09:52:31 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id 4F31713C458 for ; Sun, 17 Feb 2008 09:52:31 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so1044433rvb.43 for ; Sun, 17 Feb 2008 01:52:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=FYkLNsZLeHs/SudcEOuAzPcINEWLlf9fsRDFfhyhgZo=; b=Zx1B2+jwdGAFCvx0GMuNF8q4c8kVCJjAcVsflDcHT6R56i87UvvT4XDtZ/cbf1AdR1fmS0n3LlCe6+9QHJfcR89kTNlqxAfWfZxnrQk0D0O5n9ansWzx3UZf547x//PWU/e1rafhJteOHpv8BwFMaXK4T8pdHKrPJbc9MTvjpRI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=lv0r4rgD/wPfM7nT+OZiucoKiOtvJShWNpUoWZ9mro8WnttzTXZx6hvQfTjohOFeLcBfLjWplhQxf8i3uDdOcrQmwQV4VV2b0dXaiPFWlFpnKM+epD/+LxprvxVtRbuqXzA9F6Dkhmo+1VHF7XXWvdETUA1yZvMGom5wB4lJ6q4= Received: by 10.141.50.17 with SMTP id c17mr3009434rvk.295.1203241950369; Sun, 17 Feb 2008 01:52:30 -0800 (PST) Received: by 10.141.170.18 with HTTP; Sun, 17 Feb 2008 01:52:30 -0800 (PST) Message-ID: <2e77fc10802170152m1ae8332es512b180aeed3a837@mail.gmail.com> Date: Sun, 17 Feb 2008 11:52:30 +0200 From: "Niki Denev" Sender: ndenev@gmail.com To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 8bf63bd564f851dc Subject: ZFS snapshot problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2008 09:52:31 -0000 I started seeing this in the last few days : # zfs list | grep zfs2/backups zfs2/backups 759M 454G 747M /zfs2/backups zfs2/backups@16-02-08 11.9M - 747M - zfs2/backups@17-02-08 0 - 747M - # ls -la /zfs2/backups/.zfs/ ls: snapshot: Bad file descriptor And the snapshots seem inaccessible... Any ideas are appreciated. The machine is running 7.0-PRERELEASE from 02/02/08, and has 5 days uptime (the problem began 2 days ago, judging from my backup script mails) --Niki From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 04:36:46 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C8BB16A421; Mon, 18 Feb 2008 04:36:46 +0000 (UTC) (envelope-from freebsd@electron-tube.net) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by mx1.freebsd.org (Postfix) with ESMTP id 3367613C468; Mon, 18 Feb 2008 04:36:46 +0000 (UTC) (envelope-from freebsd@electron-tube.net) Received: from [10.0.0.100] (c-66-41-19-246.hsd1.mn.comcast.net [66.41.19.246]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1JQxY10LmJ-0007KF; Sun, 17 Feb 2008 23:24:13 -0500 Message-ID: <47B90868.7000900@electron-tube.net> Date: Sun, 17 Feb 2008 22:24:08 -0600 From: Jim Bryant User-Agent: Thunderbird 1.5 (X11/20061230) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18m4aZlpkrjVLAus8S+nj9gMeQSg5ef1kVfeL5 kBvaXrPkqcAljL7hUedzmZ1BOHwODKY8ldhtqzyKn8pRB4DeKh 4bKiIPYGZxwcwiK7ZMCUAgx2hLv+EHY Cc: freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 04:36:46 -0000 One line summary: Too many files in a top-level UFS-2 filesystem directory will cause a panic on mount. Kern/Critical/High Priority/SW-Bug Which FreeBSD Release You Are Using: 6.3-STABLE Environment (output of "uname -a" on the problem machine): FreeBSD wahoo.sd67dfl.org 6.3-STABLE FreeBSD 6.3-STABLE #0: Sun Feb 10 21:13:39 CST 2008 jbryant@wahoo.sd67dfl.org:/usr/obj/usr/src/sys/WAHOO-SMP i386 Note: I just cvsupped earlier, and no changes have been put into cvsup that would fix this problem. Full Description: I was doing a reorganization of my filesystems, and since I do offline installs, I keep a local distfiles collection (or did until yesterday when this happened), and in the process, put all of the distfiles on their own filesystem to be mounted under /usr/ports/distfiles. All was fine until I rebooted. On rebooting, I got a page fault panic on mount of the new distfiles filesystem. i booted again, got it again, booted again this time into single-user, and did a fsck on the filesystem, and it only showed as being "dirty", but otherwise had no problems in the eyes of fsck. booted again, instant panic. i booted an older 6.2 CD and mounted the filesystem fine. i then put that filesystem the way it was by mkdir'ing a distfiles dir and mv'ing everything into it, but on reboot it still paniced on mount. only a newfs was able to enable the filesystem to be mounted. today i did further research, thinking it had to do with the number of files in the top-level filesystem directory, and found that to be true. the short c program in the next section (how to repeat the problem) contains this. a second test shows that, after a newfs, if this done in any subdirectory of that filesystem, the panic is averted, and all is well. apparently this bug only effects top-level directories of a UFS2 filesystem. I have not attempted this to a non-UFS2 filesystem. IMHO, a security advisory should be released, since any user with write access to ANY top level directory of ANY mounted filesystem (most systems have /tmp as a world writable top level filesystem directory) can create a panic situation requiring a newfs of the said filesystem. A malicious user with root access can do this to /. Either way, on boot, or any attempt to mount said filesystem on a running system, will cause a panic, which of course will cause an unbootable system on reboot. How to repeat the problem: Compile and run the following as instructed: #include #include int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, 1024); for(i = 0; i < 10000; i++) { sprintf(buf, "touch %s%05d\n", argv[1], i); system((const char *)buf);} return(0);} /* pass a top-level mountpoint directory name of a mounted filesystem, with a trailing slash to the above as argv[1], and run. This will create 10,000 zero-length files in the specified directory. umount that filesystem. perform a shitload of sync's to make sure everything outstanding is flushed to disk on all filesystems. mount the target filesystem (preferably from a vty or serial console to catch the messages when it panics, which it will as soon as the mount is attempted). */ Fix to the problem if known: newfs(8) From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 04:58:47 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 847FE16A419; Mon, 18 Feb 2008 04:58:47 +0000 (UTC) (envelope-from freebsd@electron-tube.net) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4D54213C447; Mon, 18 Feb 2008 04:58:47 +0000 (UTC) (envelope-from freebsd@electron-tube.net) Received: from [10.0.0.100] (c-66-41-19-246.hsd1.mn.comcast.net [66.41.19.246]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1JQy5R0Kry-0003kN; Sun, 17 Feb 2008 23:58:46 -0500 Message-ID: <47B91080.9010109@electron-tube.net> Date: Sun, 17 Feb 2008 22:58:40 -0600 From: Jim Bryant User-Agent: Thunderbird 1.5 (X11/20061230) MIME-Version: 1.0 To: Jim Bryant References: <47B90868.7000900@electron-tube.net> In-Reply-To: <47B90868.7000900@electron-tube.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+TSUngQSCLZj+rWqUub9RwbMJN1nqDMkMpISR 1WRDrxdOUfQ9zTCoTOTZMh1eiKT5A/hSaexTQe1EGjGhEOSK3r B28Pl8SI7AAWxjBu2uOxFvX6z4laLVr Cc: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 04:58:47 -0000 FYI: The system assigned kern/120781 to this bug report. IMHO, a security advisory should be issued ASAP. Jim Bryant wrote: > One line summary: > Too many files in a top-level UFS-2 filesystem directory will cause > a panic on mount. > > Kern/Critical/High Priority/SW-Bug > > Which FreeBSD Release You Are Using: > 6.3-STABLE > > Environment (output of "uname -a" on the problem machine): > FreeBSD wahoo.sd67dfl.org 6.3-STABLE FreeBSD 6.3-STABLE #0: Sun Feb > 10 21:13:39 CST 2008 > jbryant@wahoo.sd67dfl.org:/usr/obj/usr/src/sys/WAHOO-SMP i386 > > Note: I just cvsupped earlier, and no changes have been put into > cvsup that would fix this problem. > > Full Description: > I was doing a reorganization of my filesystems, and since I do > offline installs, I keep a local distfiles collection (or did until > yesterday when this happened), and in the process, put all of the > distfiles on their own filesystem to be mounted under > /usr/ports/distfiles. > > All was fine until I rebooted. > > On rebooting, I got a page fault panic on mount of the new distfiles > filesystem. > > i booted again, got it again, booted again this time into single-user, > and did a fsck on the filesystem, and it only showed as being "dirty", > but otherwise had no problems in the eyes of fsck. booted again, > instant panic. > > i booted an older 6.2 CD and mounted the filesystem fine. i then put > that filesystem the way it was by mkdir'ing a distfiles dir and mv'ing > everything into it, but on reboot it still paniced on mount. > > only a newfs was able to enable the filesystem to be mounted. > > today i did further research, thinking it had to do with the number of > files in the top-level filesystem directory, and found that to be > true. the short c program in the next section (how to repeat the > problem) contains this. > > a second test shows that, after a newfs, if this done in any > subdirectory of that filesystem, the panic is averted, and all is > well. apparently this bug only effects top-level directories of a > UFS2 filesystem. > > I have not attempted this to a non-UFS2 filesystem. > > IMHO, a security advisory should be released, since any user with > write access to ANY top level directory of ANY mounted filesystem > (most systems have /tmp as a world writable top level filesystem > directory) can create a panic situation requiring a newfs of the said > filesystem. A malicious user with root access can do this to /. > Either way, on boot, or any attempt to mount said filesystem on a > running system, will cause a panic, which of course will cause an > unbootable system on reboot. > > How to repeat the problem: > Compile and run the following as instructed: > > #include > #include > > int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, > 1024); for(i = 0; i < 10000; i++) { sprintf(buf, "touch %s%05d\n", > argv[1], i); system((const char *)buf);} return(0);} > > /* pass a top-level mountpoint directory name of a mounted filesystem, > with a trailing slash to the above as argv[1], and run. > > This will create 10,000 zero-length files in the specified directory. > > umount that filesystem. > > perform a shitload of sync's to make sure everything outstanding is > flushed to disk on all filesystems. > > mount the target filesystem (preferably from a vty or serial console > to catch the messages when it panics, which it will as soon as the > mount is attempted). > */ > > Fix to the problem if known: > newfs(8) > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 04:58:52 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D27516A4D4; Mon, 18 Feb 2008 04:58:52 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: from mail.radiokom.kr.ua (smtp.radiokom.kr.ua [193.17.174.11]) by mx1.freebsd.org (Postfix) with ESMTP id 1AACC13C442; Mon, 18 Feb 2008 04:58:50 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: by mail.radiokom.kr.ua (Postfix, from userid 1003) id D958F1D0E7; Mon, 18 Feb 2008 06:38:51 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on shayba.homenet.kr.ua X-Spam-Level: *** X-Spam-Status: No, score=3.2 required=6.0 tests=MR_NOT_ATTRIBUTED_IP, RATWR10_MESSID,RCVD_IN_SORBS autolearn=disabled version=3.1.8 Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.radiokom.kr.ua (Postfix) with ESMTP id 9DE601D093 for ; Mon, 18 Feb 2008 06:38:46 +0200 (EET) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 944255C137; Mon, 18 Feb 2008 04:37:23 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9BC9216A509; Mon, 18 Feb 2008 04:37:21 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C8BB16A421; Mon, 18 Feb 2008 04:36:46 +0000 (UTC) (envelope-from freebsd@electron-tube.net) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by mx1.freebsd.org (Postfix) with ESMTP id 3367613C468; Mon, 18 Feb 2008 04:36:46 +0000 (UTC) (envelope-from freebsd@electron-tube.net) Received: from [10.0.0.100] (c-66-41-19-246.hsd1.mn.comcast.net [66.41.19.246]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1JQxY10LmJ-0007KF; Sun, 17 Feb 2008 23:24:13 -0500 Message-ID: <47B90868.7000900@electron-tube.net> Date: Sun, 17 Feb 2008 22:24:08 -0600 From: Jim Bryant User-Agent: Thunderbird 1.5 (X11/20061230) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18m4aZlpkrjVLAus8S+nj9gMeQSg5ef1kVfeL5 kBvaXrPkqcAljL7hUedzmZ1BOHwODKY8ldhtqzyKn8pRB4DeKh 4bKiIPYGZxwcwiK7ZMCUAgx2hLv+EHY X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-security@freebsd.org Errors-To: owner-freebsd-security@freebsd.org Cc: freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 04:58:52 -0000 One line summary: Too many files in a top-level UFS-2 filesystem directory will cause a panic on mount. Kern/Critical/High Priority/SW-Bug Which FreeBSD Release You Are Using: 6.3-STABLE Environment (output of "uname -a" on the problem machine): FreeBSD wahoo.sd67dfl.org 6.3-STABLE FreeBSD 6.3-STABLE #0: Sun Feb 10 21:13:39 CST 2008 jbryant@wahoo.sd67dfl.org:/usr/obj/usr/src/sys/WAHOO-SMP i386 Note: I just cvsupped earlier, and no changes have been put into cvsup that would fix this problem. Full Description: I was doing a reorganization of my filesystems, and since I do offline installs, I keep a local distfiles collection (or did until yesterday when this happened), and in the process, put all of the distfiles on their own filesystem to be mounted under /usr/ports/distfiles. All was fine until I rebooted. On rebooting, I got a page fault panic on mount of the new distfiles filesystem. i booted again, got it again, booted again this time into single-user, and did a fsck on the filesystem, and it only showed as being "dirty", but otherwise had no problems in the eyes of fsck. booted again, instant panic. i booted an older 6.2 CD and mounted the filesystem fine. i then put that filesystem the way it was by mkdir'ing a distfiles dir and mv'ing everything into it, but on reboot it still paniced on mount. only a newfs was able to enable the filesystem to be mounted. today i did further research, thinking it had to do with the number of files in the top-level filesystem directory, and found that to be true. the short c program in the next section (how to repeat the problem) contains this. a second test shows that, after a newfs, if this done in any subdirectory of that filesystem, the panic is averted, and all is well. apparently this bug only effects top-level directories of a UFS2 filesystem. I have not attempted this to a non-UFS2 filesystem. IMHO, a security advisory should be released, since any user with write access to ANY top level directory of ANY mounted filesystem (most systems have /tmp as a world writable top level filesystem directory) can create a panic situation requiring a newfs of the said filesystem. A malicious user with root access can do this to /. Either way, on boot, or any attempt to mount said filesystem on a running system, will cause a panic, which of course will cause an unbootable system on reboot. How to repeat the problem: Compile and run the following as instructed: #include #include int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, 1024); for(i = 0; i < 10000; i++) { sprintf(buf, "touch %s%05d\n", argv[1], i); system((const char *)buf);} return(0);} /* pass a top-level mountpoint directory name of a mounted filesystem, with a trailing slash to the above as argv[1], and run. This will create 10,000 zero-length files in the specified directory. umount that filesystem. perform a shitload of sync's to make sure everything outstanding is flushed to disk on all filesystems. mount the target filesystem (preferably from a vty or serial console to catch the messages when it panics, which it will as soon as the mount is attempted). */ Fix to the problem if known: newfs(8) _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 05:03:57 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B78016A419; Mon, 18 Feb 2008 05:03:57 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: from mail.radiokom.kr.ua (smtp.radiokom.kr.ua [193.17.174.11]) by mx1.freebsd.org (Postfix) with ESMTP id 140FD13C442; Mon, 18 Feb 2008 05:03:57 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: by mail.radiokom.kr.ua (Postfix, from userid 1003) id 3AE731D0A6; Mon, 18 Feb 2008 07:03:56 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on shayba.homenet.kr.ua X-Spam-Level: *** X-Spam-Status: No, score=3.2 required=6.0 tests=MR_NOT_ATTRIBUTED_IP, RATWR10_MESSID,RCVD_IN_SORBS autolearn=disabled version=3.1.8 Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.radiokom.kr.ua (Postfix) with ESMTP id 6C1A91D058 for ; Mon, 18 Feb 2008 07:03:51 +0200 (EET) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 51BF55D0E0; Mon, 18 Feb 2008 04:59:11 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 726E316A681; Mon, 18 Feb 2008 04:59:02 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 847FE16A419; Mon, 18 Feb 2008 04:58:47 +0000 (UTC) (envelope-from freebsd@electron-tube.net) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4D54213C447; Mon, 18 Feb 2008 04:58:47 +0000 (UTC) (envelope-from freebsd@electron-tube.net) Received: from [10.0.0.100] (c-66-41-19-246.hsd1.mn.comcast.net [66.41.19.246]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1JQy5R0Kry-0003kN; Sun, 17 Feb 2008 23:58:46 -0500 Message-ID: <47B91080.9010109@electron-tube.net> Date: Sun, 17 Feb 2008 22:58:40 -0600 From: Jim Bryant User-Agent: Thunderbird 1.5 (X11/20061230) MIME-Version: 1.0 To: Jim Bryant References: <47B90868.7000900@electron-tube.net> In-Reply-To: <47B90868.7000900@electron-tube.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+TSUngQSCLZj+rWqUub9RwbMJN1nqDMkMpISR 1WRDrxdOUfQ9zTCoTOTZMh1eiKT5A/hSaexTQe1EGjGhEOSK3r B28Pl8SI7AAWxjBu2uOxFvX6z4laLVr X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-security@freebsd.org Errors-To: owner-freebsd-security@freebsd.org Cc: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 05:03:57 -0000 FYI: The system assigned kern/120781 to this bug report. IMHO, a security advisory should be issued ASAP. Jim Bryant wrote: > One line summary: > Too many files in a top-level UFS-2 filesystem directory will cause > a panic on mount. > > Kern/Critical/High Priority/SW-Bug > > Which FreeBSD Release You Are Using: > 6.3-STABLE > > Environment (output of "uname -a" on the problem machine): > FreeBSD wahoo.sd67dfl.org 6.3-STABLE FreeBSD 6.3-STABLE #0: Sun Feb > 10 21:13:39 CST 2008 > jbryant@wahoo.sd67dfl.org:/usr/obj/usr/src/sys/WAHOO-SMP i386 > > Note: I just cvsupped earlier, and no changes have been put into > cvsup that would fix this problem. > > Full Description: > I was doing a reorganization of my filesystems, and since I do > offline installs, I keep a local distfiles collection (or did until > yesterday when this happened), and in the process, put all of the > distfiles on their own filesystem to be mounted under > /usr/ports/distfiles. > > All was fine until I rebooted. > > On rebooting, I got a page fault panic on mount of the new distfiles > filesystem. > > i booted again, got it again, booted again this time into single-user, > and did a fsck on the filesystem, and it only showed as being "dirty", > but otherwise had no problems in the eyes of fsck. booted again, > instant panic. > > i booted an older 6.2 CD and mounted the filesystem fine. i then put > that filesystem the way it was by mkdir'ing a distfiles dir and mv'ing > everything into it, but on reboot it still paniced on mount. > > only a newfs was able to enable the filesystem to be mounted. > > today i did further research, thinking it had to do with the number of > files in the top-level filesystem directory, and found that to be > true. the short c program in the next section (how to repeat the > problem) contains this. > > a second test shows that, after a newfs, if this done in any > subdirectory of that filesystem, the panic is averted, and all is > well. apparently this bug only effects top-level directories of a > UFS2 filesystem. > > I have not attempted this to a non-UFS2 filesystem. > > IMHO, a security advisory should be released, since any user with > write access to ANY top level directory of ANY mounted filesystem > (most systems have /tmp as a world writable top level filesystem > directory) can create a panic situation requiring a newfs of the said > filesystem. A malicious user with root access can do this to /. > Either way, on boot, or any attempt to mount said filesystem on a > running system, will cause a panic, which of course will cause an > unbootable system on reboot. > > How to repeat the problem: > Compile and run the following as instructed: > > #include > #include > > int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, > 1024); for(i = 0; i < 10000; i++) { sprintf(buf, "touch %s%05d\n", > argv[1], i); system((const char *)buf);} return(0);} > > /* pass a top-level mountpoint directory name of a mounted filesystem, > with a trailing slash to the above as argv[1], and run. > > This will create 10,000 zero-length files in the specified directory. > > umount that filesystem. > > perform a shitload of sync's to make sure everything outstanding is > flushed to disk on all filesystems. > > mount the target filesystem (preferably from a vty or serial console > to catch the messages when it panics, which it will as soon as the > mount is attempted). > */ > > Fix to the problem if known: > newfs(8) > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org" > _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 09:28:45 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22F9616A418 for ; Mon, 18 Feb 2008 09:28:45 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id 64EAE13C461 for ; Mon, 18 Feb 2008 09:28:44 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so1330178rvb.43 for ; Mon, 18 Feb 2008 01:28:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=FiC+27jupbvM4SzOr/JePtEqw7EFHh6LMWMu1Cg7fwM=; b=Jz0kmi89rFKhDooBP4wI+iW/C5RQqRqSAY3Nnw1XCQwZnNOl8d9jNDyibVreUJJCQwhH2I2T11LOz/2mxXXB6b+x2GrXiTAuXTHA5wdPpecqEQls13vDxqwQ7SyFCubxUvOsgEC/xYq2DHrPU6oWCp1aOykNNSJgDfDV542NDrw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=vLYJwEUaiRYdDL7D1+7h1RuUurp9+OdiEbYAFavcxiu4ftAYE3EBdKYlanuCrxuz/TosVKPTocIC0xOT8W04JlBhmIvP8p3+L6xeTgDqy/M6PPhO8+qFJBevUubY2JSDl1jGNAaU0thdPagSQ5KN0WsLWFVeiIEpa6FXrW/tLYE= Received: by 10.141.206.13 with SMTP id i13mr3655549rvq.100.1203326923841; Mon, 18 Feb 2008 01:28:43 -0800 (PST) Received: by 10.141.170.18 with HTTP; Mon, 18 Feb 2008 01:28:38 -0800 (PST) Message-ID: <2e77fc10802180128w538d014bk17469fbabb431b99@mail.gmail.com> Date: Mon, 18 Feb 2008 11:28:38 +0200 From: "Niki Denev" Sender: ndenev@gmail.com To: freebsd-fs@freebsd.org In-Reply-To: <2e77fc10802170152m1ae8332es512b180aeed3a837@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2e77fc10802170152m1ae8332es512b180aeed3a837@mail.gmail.com> X-Google-Sender-Auth: ac87a7bd2a9c25bb Cc: Pawel Jakub Dawidek Subject: Re: ZFS snapshot problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 09:28:45 -0000 On Feb 17, 2008 11:52 AM, Niki Denev wrote: > I started seeing this in the last few days : > > # zfs list | grep zfs2/backups > zfs2/backups 759M 454G 747M /zfs2/backups > zfs2/backups@16-02-08 11.9M - 747M - > zfs2/backups@17-02-08 0 - 747M - > > # ls -la /zfs2/backups/.zfs/ > ls: snapshot: Bad file descriptor > > And the snapshots seem inaccessible... Any ideas are appreciated. > > The machine is running 7.0-PRERELEASE from 02/02/08, > and has 5 days uptime (the problem began 2 days ago, judging from my > backup script mails) > Today when i tried to unmount the zfs2/backups dataset (with zfs umount zfs2/backups) the machine crashed immediately. Here is the panic msg and backtrace : Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc0 fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff804800d5 stack pointer = 0x10:0xffffffffd7836980 frame pointer = 0x10:0xffffffffd7836a20 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 70668 (zfs) trap number = 12 panic: page fault cpuid = 0 Uptime: 6d20h24m55s Physical memory: 2034 MB Dumping 1538 MB: 1523 1507 1491 1475 1459 1443 1427 1411 1395 1379 1363 1347 1331 1315 1299 1283 1267 1251 1235 1219 1203 1187 1171 1155 1139 1123 1107 1091 1075 1059 1043 1027 1011 995 979 963 947 931 915 899 883 867 851 835 819 803 787 771 755 739 723 707 691 675 659 643 627 611 595 579 563 547 531 515 499 483 467 451 435 419 403 387 371 355 339 323 307 291 275 259 243 227 211 195 179 163 147 131 115 99 83 67 51 35 19 3 #0 doadump () at pcpu.h:194 194 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:194 #1 0x0000000000000004 in avl_balance2child () #2 0xffffffff80478619 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #3 0xffffffff80478a1d in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:563 #4 0xffffffff8074f154 in trap_fatal (frame=0xffffff00015526a0, eva=18446742976121881704) at /usr/src/sys/amd64/amd64/trap.c:724 #5 0xffffffff8074f525 in trap_pfault (frame=0xffffffffd78368d0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:641 #6 0xffffffff8074fe68 in trap (frame=0xffffffffd78368d0) at /usr/src/sys/amd64/amd64/trap.c:410 #7 0xffffffff80735ace in calltrap () at /usr/src/sys/amd64/amd64/exception.S:169 #8 0xffffffff804800d5 in _sx_xlock (sx=0xa0, opts=0, file=0xffffffff80c697f0 "/usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c", line=1069) at atomic.h:142 #9 0xffffffff80c50b2a in zfsctl_umount_snapshots (vfsp=Variable "vfsp" is not available. ) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c:1069 #10 0xffffffff80c57978 in zfs_umount (vfsp=0xffffff00014f7ca0, fflag=0, td=0xffffff00015526a0) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:692 #11 0xffffffff804ebfce in dounmount (mp=0xffffff00014f7ca0, flags=0, td=0xffffff00015526a0) at /usr/src/sys/kern/vfs_mount.c:1286 #12 0xffffffff804ec7b5 in unmount (td=0xffffff00015526a0, uap=0xffffffffd7836be0) at /usr/src/sys/kern/vfs_mount.c:1182 #13 0xffffffff8074f7a7 in syscall (frame=0xffffffffd7836c70) at /usr/src/sys/amd64/amd64/trap.c:852 #14 0xffffffff80735cdb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:290 #15 0x0000000800f1396c in ?? () Previous frame inner to this frame (corrupt stack?) Seems quite similar if not the same as (and it is on the same machine) : http://lists.freebsd.org/pipermail/freebsd-fs/2008-February/004377.html --Niki From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 11:07:08 2008 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26B7A16A4EC for ; Mon, 18 Feb 2008 11:07:08 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 14D5313C4D1 for ; Mon, 18 Feb 2008 11:07:08 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1IB77Ff039383 for ; Mon, 18 Feb 2008 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1IB77mE039379 for freebsd-fs@FreeBSD.org; Mon, 18 Feb 2008 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Feb 2008 11:07:07 GMT Message-Id: <200802181107.m1IB77mE039379@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 11:07:08 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o kern/116170 fs [panic] Kernel panic when mounting /tmp 3 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o bin/118249 fs mv(1): moving a directory changes its mtime 2 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 13:23:07 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B30616A46C; Mon, 18 Feb 2008 13:23:07 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 21B0E13C4D1; Mon, 18 Feb 2008 13:23:06 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 5BF4F2083; Mon, 18 Feb 2008 14:23:00 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 46FD9207F; Mon, 18 Feb 2008 14:23:00 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 2A84F8449D; Mon, 18 Feb 2008 14:23:00 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jim Bryant References: <47B90868.7000900@electron-tube.net> Date: Mon, 18 Feb 2008 14:23:00 +0100 In-Reply-To: <47B90868.7000900@electron-tube.net> (Jim Bryant's message of "Sun\, 17 Feb 2008 22\:24\:08 -0600") Message-ID: <86odae5rgr.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 13:23:07 -0000 Jim Bryant writes: > #include > #include > > int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, 1024)= ; for(i =3D 0; i < 10000; i++) { sprintf(buf, "touch %s%05d\n", argv[1], i)= ; system((const char *)buf);} return(0);} Subject should be "how to take down a system [...] with three lines of badly written C, provided you have root privileges already and are too lazy to just dd if=3D/dev/zero of=3D/dev/ad0s1 count=3D100", which would accomplish the job much faster. Purely in the interest of showing off, here is my version. It is 81 bytes shorter than yours, it is valid C99 with POSIX extensions (yours is not), and it produces 11,450 files in about 0.2% of the time yours takes to produce 10,000. #include #define b(i,v) for(int v=3D48;v<127;++v){f[i]=3Dv; #define a(i) b(i,v##i) int main(void){char f[5]=3D{'/'};a(1)a(2)a(3)truncate(f,0);}}}} DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 13:24:36 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8D2816A46C; Mon, 18 Feb 2008 13:24:36 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: from mail.radiokom.kr.ua (smtp.radiokom.kr.ua [193.17.174.11]) by mx1.freebsd.org (Postfix) with ESMTP id 2EC9A13C4E5; Mon, 18 Feb 2008 13:24:35 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: by mail.radiokom.kr.ua (Postfix, from userid 1003) id 5DE1E1D13D; Mon, 18 Feb 2008 15:24:34 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on shayba.homenet.kr.ua X-Spam-Level: X-Spam-Status: No, score=0.0 required=6.0 tests=none autolearn=disabled version=3.1.8 Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.radiokom.kr.ua (Postfix) with ESMTP id BFBBF1CFDA for ; Mon, 18 Feb 2008 15:24:29 +0200 (EET) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 7003D1C25A; Mon, 18 Feb 2008 13:23:17 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 17F1816A52C; Mon, 18 Feb 2008 13:23:15 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B30616A46C; Mon, 18 Feb 2008 13:23:07 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 21B0E13C4D1; Mon, 18 Feb 2008 13:23:06 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 5BF4F2083; Mon, 18 Feb 2008 14:23:00 +0100 (CET) Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 46FD9207F; Mon, 18 Feb 2008 14:23:00 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 2A84F8449D; Mon, 18 Feb 2008 14:23:00 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jim Bryant References: <47B90868.7000900@electron-tube.net> Date: Mon, 18 Feb 2008 14:23:00 +0100 In-Reply-To: <47B90868.7000900@electron-tube.net> (Jim Bryant's message of "Sun\, 17 Feb 2008 22\:24\:08 -0600") Message-ID: <86odae5rgr.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-security@freebsd.org Errors-To: owner-freebsd-security@freebsd.org Cc: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 13:24:36 -0000 Jim Bryant writes: > #include > #include > > int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, 1024)= ; for(i =3D 0; i < 10000; i++) { sprintf(buf, "touch %s%05d\n", argv[1], i)= ; system((const char *)buf);} return(0);} Subject should be "how to take down a system [...] with three lines of badly written C, provided you have root privileges already and are too lazy to just dd if=3D/dev/zero of=3D/dev/ad0s1 count=3D100", which would accomplish the job much faster. Purely in the interest of showing off, here is my version. It is 81 bytes shorter than yours, it is valid C99 with POSIX extensions (yours is not), and it produces 11,450 files in about 0.2% of the time yours takes to produce 10,000. #include #define b(i,v) for(int v=3D48;v<127;++v){f[i]=3Dv; #define a(i) b(i,v##i) int main(void){char f[5]=3D{'/'};a(1)a(2)a(3)truncate(f,0);}}}} DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 13:42:46 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44DEA16A417; Mon, 18 Feb 2008 13:42:46 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: from mail.radiokom.kr.ua (smtp.radiokom.kr.ua [193.17.174.11]) by mx1.freebsd.org (Postfix) with ESMTP id BE89313C4CE; Mon, 18 Feb 2008 13:42:45 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: by mail.radiokom.kr.ua (Postfix, from userid 1003) id C38341D0F3; Mon, 18 Feb 2008 15:42:43 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on shayba.homenet.kr.ua X-Spam-Level: X-Spam-Status: No, score=0.0 required=6.0 tests=none autolearn=disabled version=3.1.8 Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.radiokom.kr.ua (Postfix) with ESMTP id 251651D09E for ; Mon, 18 Feb 2008 15:42:39 +0200 (EET) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C8D4C5F4A0; Mon, 18 Feb 2008 13:41:13 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B4A2816A4EF; Mon, 18 Feb 2008 13:41:13 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9267016A418 for ; Mon, 18 Feb 2008 13:41:06 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.244]) by mx1.freebsd.org (Postfix) with ESMTP id 501F913C455 for ; Mon, 18 Feb 2008 13:41:06 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: by ag-out-0708.google.com with SMTP id 5so2473871agb.7 for ; Mon, 18 Feb 2008 05:41:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=vq0l9z0xMsw4JpD6hWHmXb0iheAhmfajBGVA7nobMCk=; b=lgoHdV8xuG3Pk6wCyUOgAl7p80M3ORTq0MVs5nh9eJA3Naq8xE8P97UYQ5I52EwhcDykO5Q27gxOOE9A7Uhvfs+XrE1qK1UDs2c/8iWVkXpLvT20pp+fJHZEdZN618DSKUBOg4idF6fx32Zhtg9cG1TxIStgteykuruxSNCU/xc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kFxUD/W+qYjD81YNTsovhIihqaMZv14XDq+2mbEOhXyGfNOZBQ9LZb7NaUMYeJvbcI40zqqqK/MhQWnVj2FAiGs6jeEzI7MtSA0jLmTp682GLnnMlJ00rx6ql9r8e24FAqlcpnkDmp3JNZ4TMZ8QrWakjDVEm1t19eu9JARwe7I= Received: by 10.142.216.9 with SMTP id o9mr4282453wfg.173.1203341221352; Mon, 18 Feb 2008 05:27:01 -0800 (PST) Received: by 10.142.87.9 with HTTP; Mon, 18 Feb 2008 05:27:01 -0800 (PST) Message-ID: Date: Mon, 18 Feb 2008 13:27:01 +0000 From: "Kurt Buff" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86odae5rgr.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <47B90868.7000900@electron-tube.net> <86odae5rgr.fsf@ds4.des.no> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-security@freebsd.org Errors-To: owner-freebsd-security@freebsd.org Cc: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, freebsd-stable@freebsd.org, FreeBSD-bugs@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 13:42:46 -0000 Patient: Doctor, it hurts when I do this! Doctor: Don't do that... On Feb 18, 2008 1:23 PM, Dag-Erling Sm=F8rgrav wrote: > Jim Bryant writes: > > #include > > #include > > > > int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, 102= 4); for(i =3D 0; i < 10000; i++) { sprintf(buf, "touch %s%05d\n", argv[1], = i); system((const char *)buf);} return(0);} > > Subject should be "how to take down a system [...] with three lines of > badly written C, provided you have root privileges already and are too > lazy to just dd if=3D/dev/zero of=3D/dev/ad0s1 count=3D100", which would > accomplish the job much faster. > > Purely in the interest of showing off, here is my version. It is 81 > bytes shorter than yours, it is valid C99 with POSIX extensions (yours > is not), and it produces 11,450 files in about 0.2% of the time yours > takes to produce 10,000. > > #include > #define b(i,v) for(int v=3D48;v<127;++v){f[i]=3Dv; > #define a(i) b(i,v##i) > int main(void){char f[5]=3D{'/'};a(1)a(2)a(3)truncate(f,0);}}}} > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.or= g" > _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 13:43:22 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F17416A41A for ; Mon, 18 Feb 2008 13:43:22 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.243]) by mx1.freebsd.org (Postfix) with ESMTP id D627A13C465 for ; Mon, 18 Feb 2008 13:43:20 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: by ag-out-0708.google.com with SMTP id 5so2476228agb.7 for ; Mon, 18 Feb 2008 05:43:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=vq0l9z0xMsw4JpD6hWHmXb0iheAhmfajBGVA7nobMCk=; b=lgoHdV8xuG3Pk6wCyUOgAl7p80M3ORTq0MVs5nh9eJA3Naq8xE8P97UYQ5I52EwhcDykO5Q27gxOOE9A7Uhvfs+XrE1qK1UDs2c/8iWVkXpLvT20pp+fJHZEdZN618DSKUBOg4idF6fx32Zhtg9cG1TxIStgteykuruxSNCU/xc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kFxUD/W+qYjD81YNTsovhIihqaMZv14XDq+2mbEOhXyGfNOZBQ9LZb7NaUMYeJvbcI40zqqqK/MhQWnVj2FAiGs6jeEzI7MtSA0jLmTp682GLnnMlJ00rx6ql9r8e24FAqlcpnkDmp3JNZ4TMZ8QrWakjDVEm1t19eu9JARwe7I= Received: by 10.142.216.9 with SMTP id o9mr4282453wfg.173.1203341221352; Mon, 18 Feb 2008 05:27:01 -0800 (PST) Received: by 10.142.87.9 with HTTP; Mon, 18 Feb 2008 05:27:01 -0800 (PST) Message-ID: Date: Mon, 18 Feb 2008 13:27:01 +0000 From: "Kurt Buff" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86odae5rgr.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <47B90868.7000900@electron-tube.net> <86odae5rgr.fsf@ds4.des.no> Cc: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, freebsd-stable@freebsd.org, FreeBSD-bugs@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 13:43:22 -0000 Patient: Doctor, it hurts when I do this! Doctor: Don't do that... On Feb 18, 2008 1:23 PM, Dag-Erling Sm=F8rgrav wrote: > Jim Bryant writes: > > #include > > #include > > > > int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, 102= 4); for(i =3D 0; i < 10000; i++) { sprintf(buf, "touch %s%05d\n", argv[1], = i); system((const char *)buf);} return(0);} > > Subject should be "how to take down a system [...] with three lines of > badly written C, provided you have root privileges already and are too > lazy to just dd if=3D/dev/zero of=3D/dev/ad0s1 count=3D100", which would > accomplish the job much faster. > > Purely in the interest of showing off, here is my version. It is 81 > bytes shorter than yours, it is valid C99 with POSIX extensions (yours > is not), and it produces 11,450 files in about 0.2% of the time yours > takes to produce 10,000. > > #include > #define b(i,v) for(int v=3D48;v<127;++v){f[i]=3Dv; > #define a(i) b(i,v##i) > int main(void){char f[5]=3D{'/'};a(1)a(2)a(3)truncate(f,0);}}}} > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.or= g" > From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 13:54:06 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9ED916A418; Mon, 18 Feb 2008 13:54:06 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id A49D413C45E; Mon, 18 Feb 2008 13:54:06 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 59B252090; Mon, 18 Feb 2008 14:53:59 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 438A52087; Mon, 18 Feb 2008 14:53:59 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 1A0068449D; Mon, 18 Feb 2008 14:53:59 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jim Bryant References: <47B90868.7000900@electron-tube.net> <86odae5rgr.fsf@ds4.des.no> Date: Mon, 18 Feb 2008 14:53:59 +0100 In-Reply-To: <86odae5rgr.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Mon\, 18 Feb 2008 14\:23\:00 +0100") Message-ID: <863arq5q14.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 13:54:07 -0000 Dag-Erling Sm=C3=B8rgrav writes: > Purely in the interest of showing off, here is my version. It is 81 > bytes shorter than yours, it is valid C99 with POSIX extensions (yours > is not), and it produces 11,450 files in about 0.2% of the time yours > takes to produce 10,000. > > #include > #define b(i,v) for(int v=3D48;v<127;++v){f[i]=3Dv; > #define a(i) b(i,v##i) > int main(void){char f[5]=3D{'/'};a(1)a(2)a(3)truncate(f,0);}}}} Two bugs: 1) I forgot to include the correct version of the code 2) the version I had created a few files with '/' in their names; this slightly nastier creates 10,648 files with only letters. #include #define b(i,v)for(int v=3D65;v<87;){i[f]=3Dv++; #define a(i)b(i,v##i) int main(void){char f[4]=3D{47};a(1)a(2)a(3)truncate(f,0);}}}} DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 13:54:49 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DDC116A418; Mon, 18 Feb 2008 13:54:49 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: from mail.radiokom.kr.ua (smtp.radiokom.kr.ua [193.17.174.11]) by mx1.freebsd.org (Postfix) with ESMTP id 7991B13C46A; Mon, 18 Feb 2008 13:54:48 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: by mail.radiokom.kr.ua (Postfix, from userid 1003) id 801CF1D170; Mon, 18 Feb 2008 15:54:46 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on shayba.homenet.kr.ua X-Spam-Level: X-Spam-Status: No, score=0.0 required=6.0 tests=none autolearn=disabled version=3.1.8 Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.radiokom.kr.ua (Postfix) with ESMTP id 685781D058 for ; Mon, 18 Feb 2008 15:54:41 +0200 (EET) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id A6D4F5F38A; Mon, 18 Feb 2008 13:54:16 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 275C516A4E5; Mon, 18 Feb 2008 13:54:16 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9ED916A418; Mon, 18 Feb 2008 13:54:06 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id A49D413C45E; Mon, 18 Feb 2008 13:54:06 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 59B252090; Mon, 18 Feb 2008 14:53:59 +0100 (CET) Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 438A52087; Mon, 18 Feb 2008 14:53:59 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 1A0068449D; Mon, 18 Feb 2008 14:53:59 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jim Bryant References: <47B90868.7000900@electron-tube.net> <86odae5rgr.fsf@ds4.des.no> Date: Mon, 18 Feb 2008 14:53:59 +0100 In-Reply-To: <86odae5rgr.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Mon\, 18 Feb 2008 14\:23\:00 +0100") Message-ID: <863arq5q14.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-security@freebsd.org Errors-To: owner-freebsd-security@freebsd.org Cc: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 13:54:49 -0000 Dag-Erling Sm=C3=B8rgrav writes: > Purely in the interest of showing off, here is my version. It is 81 > bytes shorter than yours, it is valid C99 with POSIX extensions (yours > is not), and it produces 11,450 files in about 0.2% of the time yours > takes to produce 10,000. > > #include > #define b(i,v) for(int v=3D48;v<127;++v){f[i]=3Dv; > #define a(i) b(i,v##i) > int main(void){char f[5]=3D{'/'};a(1)a(2)a(3)truncate(f,0);}}}} Two bugs: 1) I forgot to include the correct version of the code 2) the version I had created a few files with '/' in their names; this slightly nastier creates 10,648 files with only letters. #include #define b(i,v)for(int v=3D65;v<87;){i[f]=3Dv++; #define a(i)b(i,v##i) int main(void){char f[4]=3D{47};a(1)a(2)a(3)truncate(f,0);}}}} DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 14:09:31 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED54C16A417; Mon, 18 Feb 2008 14:09:31 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 9D8F013C442; Mon, 18 Feb 2008 14:09:31 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from scoo-longs-computer.local (74-92-209-69-Colorado.hfc.comcastbusiness.net [74.92.209.69] (may be forged)) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id m1IE9FaX012939; Mon, 18 Feb 2008 07:09:21 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <47B9918B.6010301@samsco.org> Date: Mon, 18 Feb 2008 07:09:15 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <47B90868.7000900@electron-tube.net> <86odae5rgr.fsf@ds4.des.no> <863arq5q14.fsf@ds4.des.no> In-Reply-To: <863arq5q14.fsf@ds4.des.no> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.0 required=5.4 tests=none autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, freebsd-stable@freebsd.org, FreeBSD-bugs@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 14:09:32 -0000 Dag-Erling Smørgrav wrote: > Dag-Erling Smørgrav writes: >> Purely in the interest of showing off, here is my version. It is 81 >> bytes shorter than yours, it is valid C99 with POSIX extensions (yours >> is not), and it produces 11,450 files in about 0.2% of the time yours >> takes to produce 10,000. >> >> #include >> #define b(i,v) for(int v=48;v<127;++v){f[i]=v; >> #define a(i) b(i,v##i) >> int main(void){char f[5]={'/'};a(1)a(2)a(3)truncate(f,0);}}}} > > Two bugs: > > 1) I forgot to include the correct version of the code > > 2) the version I had created a few files with '/' in their names; this > slightly nastier creates 10,648 files with only letters. > > #include > #define b(i,v)for(int v=65;v<87;){i[f]=v++; > #define a(i)b(i,v##i) > int main(void){char f[4]={47};a(1)a(2)a(3)truncate(f,0);}}}} > > DES This version also omits the constructive comments on the actual problem that the original poster identified. Scott From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 14:13:21 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 476C616A41A for ; Mon, 18 Feb 2008 14:13:21 +0000 (UTC) (envelope-from speedtoys.racing@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.237]) by mx1.freebsd.org (Postfix) with ESMTP id EB21B13C513 for ; Mon, 18 Feb 2008 14:13:20 +0000 (UTC) (envelope-from speedtoys.racing@gmail.com) Received: by qb-out-0506.google.com with SMTP id a10so1634540qbd.7 for ; Mon, 18 Feb 2008 06:13:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to:in-reply-to:content-type:x-mailer:mime-version:subject:content-transfer-encoding:date:cc; bh=9bLxeBN1YR5P3J2TSpLos4itvksm2Ux1AanE2niW2bg=; b=ZOyEdss95X3i8MhsBN78Bfix8JDkL7TFMi4gMJYZ9EUIZPkyEujwimahKNvfu/IqNOGN38fjogkwzGfq4ywdYDY+5ieboOoWspZCZgkd4yhDEKMEqn8uAfIAIkPBGw/xp91bDgLf4mcd+dThBCKcxBmeiUjytb45XtIO5EnwCgQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type:x-mailer:mime-version:subject:content-transfer-encoding:date:cc; b=K8WTuo+gYNAU8BscKx9WUJ+sYcbKzVrxD9L63QBa+ggoz5AZwSDBAoRJnt5kcjoqK1gwLS8RG0+1Dc3JWgBSId99lhXsVcrKKB1Tn4I9SrI4c70JG3jGYX7THSqyBt1KufWhilFPjRl9dlaefKk8JM6FiKRPfsv+v8FPT5B5/ms= Received: by 10.110.68.10 with SMTP id q10mr3339856tia.28.1203343083226; Mon, 18 Feb 2008 05:58:03 -0800 (PST) Received: from ?10.6.146.10? ( [166.193.195.177]) by mx.google.com with ESMTPS id h18sm10024404wxd.18.2008.02.18.05.57.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Feb 2008 05:58:01 -0800 (PST) References: <47B90868.7000900@electron-tube.net> <86odae5rgr.fsf@ds4.des.no> Message-Id: From: Speedtoys To: Kurt Buff In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes X-Mailer: iPhone Mail (4A93) Mime-Version: 1.0 (iPhone Mail 4A93) Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Feb 2008 08:57:46 -0500 Cc: "freebsd-fs@freebsd.org" , =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , "FreeBSD-bugs@freebsd.org" , "freebsd-stable@freebsd.org" , "freebsd-security@freebsd.org" Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 14:13:21 -0000 Time for the idiot(proof) function call. Got brakes? =3D=3D=3D=3D=3D=3D 25hrs or one season with one pad set is possible. Save money and pit =20= time, compromise nothing. Ask how. TXT or Tone: 8414546712@txt.att.net http://www.speedtoys.com On Feb 18, 2008, at 8:27 AM, "Kurt Buff" wrote: > Patient: Doctor, it hurts when I do this! > > Doctor: Don't do that... > > On Feb 18, 2008 1:23 PM, Dag-Erling Sm=C3=B8rgrav wrote: >> Jim Bryant writes: >>> #include >>> #include >>> >>> int main(int argc, char **argv) { int i; char buf[1024]; bzero=20 >>> (buf, 1024); for(i =3D 0; i < 10000; i++) { sprintf(buf, "touch %s%=20= >>> 05d\n", argv[1], i); system((const char *)buf);} return(0);} >> >> Subject should be "how to take down a system [...] with three lines =20= >> of >> badly written C, provided you have root privileges already and are =20= >> too >> lazy to just dd if=3D/dev/zero of=3D/dev/ad0s1 count=3D100", which = would >> accomplish the job much faster. >> >> Purely in the interest of showing off, here is my version. It is 81 >> bytes shorter than yours, it is valid C99 with POSIX extensions =20 >> (yours >> is not), and it produces 11,450 files in about 0.2% of the time yours >> takes to produce 10,000. >> >> #include >> #define b(i,v) for(int v=3D48;v<127;++v){f[i]=3Dv; >> #define a(i) b(i,v##i) >> int main(void){char f[5]=3D{'/'};a(1)a(2)a(3)truncate(f,0);}}}} >> >> DES >> -- >> Dag-Erling Sm=C3=B8rgrav - des@des.no >> >> _______________________________________________ >> freebsd-security@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-security >> To unsubscribe, send any mail to = "freebsd-security-unsubscribe@freebsd.org=20 >> " >> > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to = "freebsd-security-unsubscribe@freebsd.org=20 > " > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 14:14:19 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1000E16A419 for ; Mon, 18 Feb 2008 14:14:19 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) by mx1.freebsd.org (Postfix) with ESMTP id 9A22113C467 for ; Mon, 18 Feb 2008 14:14:18 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.1) with ESMTP id m1IEE8bd075081; Tue, 19 Feb 2008 01:14:08 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802181414.m1IEE8bd075081@drugs.dv.isc.org> To: "Kurt Buff" From: Mark Andrews In-reply-to: Your message of "Mon, 18 Feb 2008 13:27:01 -0000." Date: Tue, 19 Feb 2008 01:14:08 +1100 Sender: marka@isc.org Cc: FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org, freebsd-fs@freebsd.org, freebsd-security@freebsd.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 14:14:19 -0000 > Patient: Doctor, it hurts when I do this! > > Doctor: Don't do that... Did you actually bother to read his report? While his example is used "/", if the report is correct then you just need to replace "/" with the path of any file system mount point that is world writable like say "/tmp". Do you have /tmp mounted like this? /dev/ad0s4e 507630 162050 304970 35% /tmp Have you tried using "/tmp" or some other suitable mount point before slinging off with the old Doctor joke? Even if it is only "/", having the system die and not be recoverable due to having a excessive number of files in "/" is a critical error. I'm sure you have *never* accidently copied a set of files to "/" in your life. Me, I know I've made that sort of mistake in the past, and as I'm not perfect, I'm sure I'll make that sort of mistake at some point in the future. I would however like the machine not to fallover when I do make that mistake. Now why don't you be constructive and verify whether the report is valid or not. I don't have a spare machine to test it on so I'm not going to attempt it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 14:15:07 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 377C516A46D; Mon, 18 Feb 2008 14:15:07 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: from mail.radiokom.kr.ua (smtp.radiokom.kr.ua [193.17.174.11]) by mx1.freebsd.org (Postfix) with ESMTP id A217C13C4EF; Mon, 18 Feb 2008 14:15:06 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: by mail.radiokom.kr.ua (Postfix, from userid 1003) id 6BE6E1D187; Mon, 18 Feb 2008 16:15:04 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on shayba.homenet.kr.ua X-Spam-Level: X-Spam-Status: No, score=0.0 required=6.0 tests=none autolearn=disabled version=3.1.8 Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.radiokom.kr.ua (Postfix) with ESMTP id 114E61D0A9 for ; Mon, 18 Feb 2008 16:14:59 +0200 (EET) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id F3BFC60026; Mon, 18 Feb 2008 14:14:25 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 48AD816A4D1; Mon, 18 Feb 2008 14:14:25 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14D5A16A46C for ; Mon, 18 Feb 2008 14:14:15 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) by mx1.freebsd.org (Postfix) with ESMTP id C166D13C45E for ; Mon, 18 Feb 2008 14:14:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.1) with ESMTP id m1IEE8bd075081; Tue, 19 Feb 2008 01:14:08 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802181414.m1IEE8bd075081@drugs.dv.isc.org> To: "Kurt Buff" From: Mark Andrews In-reply-to: Your message of "Mon, 18 Feb 2008 13:27:01 -0000." Date: Tue, 19 Feb 2008 01:14:08 +1100 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-security@freebsd.org Errors-To: owner-freebsd-security@freebsd.org Cc: FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org, freebsd-fs@freebsd.org, freebsd-security@freebsd.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 14:15:07 -0000 > Patient: Doctor, it hurts when I do this! > > Doctor: Don't do that... Did you actually bother to read his report? While his example is used "/", if the report is correct then you just need to replace "/" with the path of any file system mount point that is world writable like say "/tmp". Do you have /tmp mounted like this? /dev/ad0s4e 507630 162050 304970 35% /tmp Have you tried using "/tmp" or some other suitable mount point before slinging off with the old Doctor joke? Even if it is only "/", having the system die and not be recoverable due to having a excessive number of files in "/" is a critical error. I'm sure you have *never* accidently copied a set of files to "/" in your life. Me, I know I've made that sort of mistake in the past, and as I'm not perfect, I'm sure I'll make that sort of mistake at some point in the future. I would however like the machine not to fallover when I do make that mistake. Now why don't you be constructive and verify whether the report is valid or not. I don't have a spare machine to test it on so I'm not going to attempt it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 14:25:51 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9647C16A418; Mon, 18 Feb 2008 14:25:51 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id EB16813C467; Mon, 18 Feb 2008 14:25:49 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id F094046B62; Mon, 18 Feb 2008 09:25:48 -0500 (EST) Date: Mon, 18 Feb 2008 14:25:48 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jim Bryant In-Reply-To: <47B91080.9010109@electron-tube.net> Message-ID: <20080218142004.O49202@fledge.watson.org> References: <47B90868.7000900@electron-tube.net> <47B91080.9010109@electron-tube.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 14:25:51 -0000 On Sun, 17 Feb 2008, Jim Bryant wrote: > FYI: The system assigned kern/120781 to this bug report. > > IMHO, a security advisory should be issued ASAP. Thanks for the report, I'm sure your widely distributed e-mail will get someone looking at it quickly. In the future if you run into an issue you think might require a security advisory, consider e-mailing it privately to secteam@FreeBSD.org so that the release of patches can cooincide with publication of the problem. That said, this is probably more a candidate for an errata patch rather than a security advisory -- security advisories are normally limited to local/remote privilege escalation or serious remote denial of service. Local denial of service problems occur in all operating systems I'm aware of with such frequency that the world would be continuously innundated with advisories to the point of rendering advisories useless if we did them every time someone discovered a way users could crash the system. You need only watch the change logs of the various open source kernels for the words "fix panic", "don't dereference NULL pointer", "don't leak a lock...", etc, to get a sense of the quantity of locally exercisable system bugs, many of which can lead to reboots, hangs, or data loss, to see why. Hopefully this bug will get resolved shortly, and then we can evaluate if an errata notice is necessary. Robert N M Watson Computer Laboratory University of Cambridge > > Jim Bryant wrote: >> One line summary: >> Too many files in a top-level UFS-2 filesystem directory will cause a >> panic on mount. >> >> Kern/Critical/High Priority/SW-Bug >> >> Which FreeBSD Release You Are Using: >> 6.3-STABLE >> >> Environment (output of "uname -a" on the problem machine): >> FreeBSD wahoo.sd67dfl.org 6.3-STABLE FreeBSD 6.3-STABLE #0: Sun Feb 10 >> 21:13:39 CST 2008 >> jbryant@wahoo.sd67dfl.org:/usr/obj/usr/src/sys/WAHOO-SMP i386 >> >> Note: I just cvsupped earlier, and no changes have been put into cvsup >> that would fix this problem. >> >> Full Description: >> I was doing a reorganization of my filesystems, and since I do offline >> installs, I keep a local distfiles collection (or did until yesterday when >> this happened), and in the process, put all of the distfiles on their own >> filesystem to be mounted under /usr/ports/distfiles. >> >> All was fine until I rebooted. >> >> On rebooting, I got a page fault panic on mount of the new distfiles >> filesystem. >> >> i booted again, got it again, booted again this time into single-user, and >> did a fsck on the filesystem, and it only showed as being "dirty", but >> otherwise had no problems in the eyes of fsck. booted again, instant >> panic. >> >> i booted an older 6.2 CD and mounted the filesystem fine. i then put that >> filesystem the way it was by mkdir'ing a distfiles dir and mv'ing >> everything into it, but on reboot it still paniced on mount. >> >> only a newfs was able to enable the filesystem to be mounted. >> >> today i did further research, thinking it had to do with the number of >> files in the top-level filesystem directory, and found that to be true. >> the short c program in the next section (how to repeat the problem) >> contains this. >> >> a second test shows that, after a newfs, if this done in any subdirectory >> of that filesystem, the panic is averted, and all is well. apparently this >> bug only effects top-level directories of a UFS2 filesystem. >> >> I have not attempted this to a non-UFS2 filesystem. >> >> IMHO, a security advisory should be released, since any user with write >> access to ANY top level directory of ANY mounted filesystem (most systems >> have /tmp as a world writable top level filesystem directory) can create a >> panic situation requiring a newfs of the said filesystem. A malicious user >> with root access can do this to /. Either way, on boot, or any attempt to >> mount said filesystem on a running system, will cause a panic, which of >> course will cause an unbootable system on reboot. >> >> How to repeat the problem: >> Compile and run the following as instructed: >> >> #include >> #include >> >> int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, 1024); >> for(i = 0; i < 10000; i++) { sprintf(buf, "touch %s%05d\n", argv[1], i); >> system((const char *)buf);} return(0);} >> >> /* pass a top-level mountpoint directory name of a mounted filesystem, with >> a trailing slash to the above as argv[1], and run. >> >> This will create 10,000 zero-length files in the specified directory. >> >> umount that filesystem. >> >> perform a shitload of sync's to make sure everything outstanding is flushed >> to disk on all filesystems. >> >> mount the target filesystem (preferably from a vty or serial console to >> catch the messages when it panics, which it will as soon as the mount is >> attempted). >> */ >> >> Fix to the problem if known: >> newfs(8) >> >> _______________________________________________ >> freebsd-security@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-security >> To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 14:27:25 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E949516A41A; Mon, 18 Feb 2008 14:27:24 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: from mail.radiokom.kr.ua (smtp.radiokom.kr.ua [193.17.174.11]) by mx1.freebsd.org (Postfix) with ESMTP id 5EF1113C4E3; Mon, 18 Feb 2008 14:27:23 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: by mail.radiokom.kr.ua (Postfix, from userid 1003) id 721A41D0F3; Mon, 18 Feb 2008 16:27:22 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on shayba.homenet.kr.ua X-Spam-Level: X-Spam-Status: No, score=0.0 required=6.0 tests=none autolearn=disabled version=3.1.8 Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.radiokom.kr.ua (Postfix) with ESMTP id 043AD1CE9C for ; Mon, 18 Feb 2008 16:27:17 +0200 (EET) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 5CC425E979; Mon, 18 Feb 2008 14:26:01 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 188A416A4C9; Mon, 18 Feb 2008 14:25:59 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9647C16A418; Mon, 18 Feb 2008 14:25:51 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id EB16813C467; Mon, 18 Feb 2008 14:25:49 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id F094046B62; Mon, 18 Feb 2008 09:25:48 -0500 (EST) Date: Mon, 18 Feb 2008 14:25:48 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jim Bryant In-Reply-To: <47B91080.9010109@electron-tube.net> Message-ID: <20080218142004.O49202@fledge.watson.org> References: <47B90868.7000900@electron-tube.net> <47B91080.9010109@electron-tube.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-security@freebsd.org Errors-To: owner-freebsd-security@freebsd.org Cc: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 14:27:25 -0000 On Sun, 17 Feb 2008, Jim Bryant wrote: > FYI: The system assigned kern/120781 to this bug report. > > IMHO, a security advisory should be issued ASAP. Thanks for the report, I'm sure your widely distributed e-mail will get someone looking at it quickly. In the future if you run into an issue you think might require a security advisory, consider e-mailing it privately to secteam@FreeBSD.org so that the release of patches can cooincide with publication of the problem. That said, this is probably more a candidate for an errata patch rather than a security advisory -- security advisories are normally limited to local/remote privilege escalation or serious remote denial of service. Local denial of service problems occur in all operating systems I'm aware of with such frequency that the world would be continuously innundated with advisories to the point of rendering advisories useless if we did them every time someone discovered a way users could crash the system. You need only watch the change logs of the various open source kernels for the words "fix panic", "don't dereference NULL pointer", "don't leak a lock...", etc, to get a sense of the quantity of locally exercisable system bugs, many of which can lead to reboots, hangs, or data loss, to see why. Hopefully this bug will get resolved shortly, and then we can evaluate if an errata notice is necessary. Robert N M Watson Computer Laboratory University of Cambridge > > Jim Bryant wrote: >> One line summary: >> Too many files in a top-level UFS-2 filesystem directory will cause a >> panic on mount. >> >> Kern/Critical/High Priority/SW-Bug >> >> Which FreeBSD Release You Are Using: >> 6.3-STABLE >> >> Environment (output of "uname -a" on the problem machine): >> FreeBSD wahoo.sd67dfl.org 6.3-STABLE FreeBSD 6.3-STABLE #0: Sun Feb 10 >> 21:13:39 CST 2008 >> jbryant@wahoo.sd67dfl.org:/usr/obj/usr/src/sys/WAHOO-SMP i386 >> >> Note: I just cvsupped earlier, and no changes have been put into cvsup >> that would fix this problem. >> >> Full Description: >> I was doing a reorganization of my filesystems, and since I do offline >> installs, I keep a local distfiles collection (or did until yesterday when >> this happened), and in the process, put all of the distfiles on their own >> filesystem to be mounted under /usr/ports/distfiles. >> >> All was fine until I rebooted. >> >> On rebooting, I got a page fault panic on mount of the new distfiles >> filesystem. >> >> i booted again, got it again, booted again this time into single-user, and >> did a fsck on the filesystem, and it only showed as being "dirty", but >> otherwise had no problems in the eyes of fsck. booted again, instant >> panic. >> >> i booted an older 6.2 CD and mounted the filesystem fine. i then put that >> filesystem the way it was by mkdir'ing a distfiles dir and mv'ing >> everything into it, but on reboot it still paniced on mount. >> >> only a newfs was able to enable the filesystem to be mounted. >> >> today i did further research, thinking it had to do with the number of >> files in the top-level filesystem directory, and found that to be true. >> the short c program in the next section (how to repeat the problem) >> contains this. >> >> a second test shows that, after a newfs, if this done in any subdirectory >> of that filesystem, the panic is averted, and all is well. apparently this >> bug only effects top-level directories of a UFS2 filesystem. >> >> I have not attempted this to a non-UFS2 filesystem. >> >> IMHO, a security advisory should be released, since any user with write >> access to ANY top level directory of ANY mounted filesystem (most systems >> have /tmp as a world writable top level filesystem directory) can create a >> panic situation requiring a newfs of the said filesystem. A malicious user >> with root access can do this to /. Either way, on boot, or any attempt to >> mount said filesystem on a running system, will cause a panic, which of >> course will cause an unbootable system on reboot. >> >> How to repeat the problem: >> Compile and run the following as instructed: >> >> #include >> #include >> >> int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, 1024); >> for(i = 0; i < 10000; i++) { sprintf(buf, "touch %s%05d\n", argv[1], i); >> system((const char *)buf);} return(0);} >> >> /* pass a top-level mountpoint directory name of a mounted filesystem, with >> a trailing slash to the above as argv[1], and run. >> >> This will create 10,000 zero-length files in the specified directory. >> >> umount that filesystem. >> >> perform a shitload of sync's to make sure everything outstanding is flushed >> to disk on all filesystems. >> >> mount the target filesystem (preferably from a vty or serial console to >> catch the messages when it panics, which it will as soon as the mount is >> attempted). >> */ >> >> Fix to the problem if known: >> newfs(8) >> >> _______________________________________________ >> freebsd-security@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-security >> To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 14:35:36 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7D7316A417; Mon, 18 Feb 2008 14:35:36 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 99F3213C45B; Mon, 18 Feb 2008 14:35:35 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m1IDxmF0062860; Mon, 18 Feb 2008 20:59:48 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m1IDxmFb062859; Mon, 18 Feb 2008 20:59:48 +0700 (KRAT) (envelope-from eugen) Date: Mon, 18 Feb 2008 20:59:48 +0700 From: Eugene Grosbein To: des@des.no Message-ID: <20080218135948.GB62360@svzserv.kemerovo.su> References: <47B90868.7000900@electron-tube.net> <86odae5rgr.fsf@ds4.des.no> <863arq5q14.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <863arq5q14.fsf@ds4.des.no> User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, freebsd-stable@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 14:35:37 -0000 On Mon, Feb 18, 2008 at 02:53:59PM +0100, Dag-Erling Sm??rgrav wrote: > Two bugs: [skip] That's all very funny, but what about a panic? It it true that it's possible for non-root to bring a file system to not-mountable state? Eugene Grosbein From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 14:36:09 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED70616A417 for ; Mon, 18 Feb 2008 14:36:09 +0000 (UTC) (envelope-from dennis.melentyev@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 7E15113C44B for ; Mon, 18 Feb 2008 14:36:09 +0000 (UTC) (envelope-from dennis.melentyev@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so1488593fgg.35 for ; Mon, 18 Feb 2008 06:36:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=m93MpZz/8SABrOJL8fhChbYxABBoZrU/I6gZdAejGwY=; b=txNLQ2SjYuOIbAUpQNLdCiQOfw36vRAHofiUK/6IMYTZJbD02yK/3EJLLrxvApzQsImy6Puy98qlc61mEW7eaR50f8ExqkUFgUOsIRBTpBSZTG2QnPu6rkhHyOrAdCLu0+kQbAbCX8nhUBci8D0g7en+FElD4BOwe+nMg712NGc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DQnQj+OULRiP+GLoCW5uQBfwI+Nqj8s3nchEhyPsJp19Lq0MduJlfJS7kpFdoJpzVYOO0iFVdlj9JzzmiuMN35yYn4X4mEy8ADiK9l7qBd4kwbv8RntJ85SD7P318YHoF7Za3oHu0BSpqgWSwqpm4vcvDbzp6BMOW6BqiWIZ8hg= Received: by 10.86.57.9 with SMTP id f9mr347796fga.28.1203343792243; Mon, 18 Feb 2008 06:09:52 -0800 (PST) Received: by 10.86.74.13 with HTTP; Mon, 18 Feb 2008 06:09:52 -0800 (PST) Message-ID: Date: Mon, 18 Feb 2008 16:09:52 +0200 From: "Dennis Melentyev" To: "=?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?=" In-Reply-To: <863arq5q14.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <47B90868.7000900@electron-tube.net> <86odae5rgr.fsf@ds4.des.no> <863arq5q14.fsf@ds4.des.no> Cc: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, freebsd-stable@freebsd.org, FreeBSD-bugs@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 14:36:10 -0000 RGFnLUVybGluZzogeW91IHdpbiEgWW91cidzIGxvbmdlciBhIGNvdXBsZSBvZiBpbmNoZXMgOikK ClNvcnJ5LCBteSBoYW5kcyBydW5zIGluIGZyb250IG9mIHRoZSBsb2NvLi4uCkhvcGUgdGhlcmUg YXJlIG5vdCBtdWNoIG9mICpzdWNoKiBzdHlsZWQgcHJlcHJvY2Vzc29yIGNvZGUgaW4gRnJlZUJT RD8KSXQgc2hvdWxkIGJlIGEgcGxhaW4gc3VpY2lkZSB0byBmaXggYSBidWcgaW4gaXQuCgoyMDA4 LzIvMTgsIERhZy1FcmxpbmcgU23DuHJncmF2IDxkZXNAZGVzLm5vPjoKPiBEYWctRXJsaW5nIFNt w7hyZ3JhdiA8ZGVzQGRlcy5ubz4gd3JpdGVzOgo+ID4gUHVyZWx5IGluIHRoZSBpbnRlcmVzdCBv ZiBzaG93aW5nIG9mZiwgaGVyZSBpcyBteSB2ZXJzaW9uLiAgSXQgaXMgODEKPiA+IGJ5dGVzIHNo b3J0ZXIgdGhhbiB5b3VycywgaXQgaXMgdmFsaWQgQzk5IHdpdGggUE9TSVggZXh0ZW5zaW9ucyAo eW91cnMKPiA+IGlzIG5vdCksIGFuZCBpdCBwcm9kdWNlcyAxMSw0NTAgZmlsZXMgaW4gYWJvdXQg MC4yJSBvZiB0aGUgdGltZSB5b3Vycwo+ID4gdGFrZXMgdG8gcHJvZHVjZSAxMCwwMDAuCj4gPgo+ ID4gI2luY2x1ZGUgPHVuaXN0ZC5oPgo+ID4gI2RlZmluZSBiKGksdikgZm9yKGludCB2PTQ4O3Y8 MTI3Oysrdil7ZltpXT12Owo+ID4gI2RlZmluZSBhKGkpIGIoaSx2IyNpKQo+ID4gaW50IG1haW4o dm9pZCl7Y2hhciBmWzVdPXsnLyd9O2EoMSlhKDIpYSgzKXRydW5jYXRlKGYsMCk7fX19fQo+Cj4g VHdvIGJ1Z3M6Cj4KPiAxKSBJIGZvcmdvdCB0byBpbmNsdWRlIHRoZSBjb3JyZWN0IHZlcnNpb24g b2YgdGhlIGNvZGUKPgo+IDIpIHRoZSB2ZXJzaW9uIEkgaGFkIGNyZWF0ZWQgYSBmZXcgZmlsZXMg d2l0aCAnLycgaW4gdGhlaXIgbmFtZXM7IHRoaXMKPiAgICBzbGlnaHRseSBuYXN0aWVyIGNyZWF0 ZXMgMTAsNjQ4IGZpbGVzIHdpdGggb25seSBsZXR0ZXJzLgo+Cj4gI2luY2x1ZGUgPHVuaXN0ZC5o Pgo+ICNkZWZpbmUgYihpLHYpZm9yKGludCB2PTY1O3Y8ODc7KXtpW2ZdPXYrKzsKPiAjZGVmaW5l IGEoaSliKGksdiMjaSkKPiBpbnQgbWFpbih2b2lkKXtjaGFyIGZbNF09ezQ3fTthKDEpYSgyKWEo Myl0cnVuY2F0ZShmLDApO319fX0KPgo+IERFUwo+IC0tCj4gRGFnLUVybGluZyBTbcO4cmdyYXYg LSBkZXNAZGVzLm5vCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KPiBmcmVlYnNkLXN0YWJsZUBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QKPiBodHRwOi8v bGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLXN0YWJsZQo+IFRvIHVu c3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLXN0YWJsZS11bnN1YnNjcmliZUBm cmVlYnNkLm9yZyIKPgoKCi0tIApEZW5uaXMgTWVsZW50eWV2Cg== From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 14:48:17 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C33516A417; Mon, 18 Feb 2008 14:48:17 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: from mail.radiokom.kr.ua (smtp.radiokom.kr.ua [193.17.174.11]) by mx1.freebsd.org (Postfix) with ESMTP id 0D4A713C457; Mon, 18 Feb 2008 14:48:16 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: by mail.radiokom.kr.ua (Postfix, from userid 1003) id 83BD31D16E; Mon, 18 Feb 2008 16:48:15 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on shayba.homenet.kr.ua X-Spam-Level: X-Spam-Status: No, score=0.0 required=6.0 tests=none autolearn=disabled version=3.1.8 Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.radiokom.kr.ua (Postfix) with ESMTP id D2CFE1D0DC for ; Mon, 18 Feb 2008 16:48:10 +0200 (EET) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 2EF402EFED; Mon, 18 Feb 2008 14:47:39 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id BA7D116A547; Mon, 18 Feb 2008 14:47:36 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C03F516A418 for ; Mon, 18 Feb 2008 14:47:28 +0000 (UTC) (envelope-from ady@ady.ro) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.242]) by mx1.freebsd.org (Postfix) with ESMTP id 863AE13C45A for ; Mon, 18 Feb 2008 14:47:28 +0000 (UTC) (envelope-from ady@ady.ro) Received: by ag-out-0708.google.com with SMTP id 5so2548706agb.7 for ; Mon, 18 Feb 2008 06:47:28 -0800 (PST) Received: by 10.142.72.21 with SMTP id u21mr4365062wfa.82.1203345155884; Mon, 18 Feb 2008 06:32:35 -0800 (PST) Received: by 10.142.109.6 with HTTP; Mon, 18 Feb 2008 06:32:35 -0800 (PST) Message-ID: <78cb3d3f0802180632u1d38ec67i432052d9c77dd706@mail.gmail.com> Date: Mon, 18 Feb 2008 16:32:35 +0200 From: "Adrian Penisoara" To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org, freebsd-security@freebsd.org In-Reply-To: <200802181414.m1IEE8bd075081@drugs.dv.isc.org> MIME-Version: 1.0 References: <200802181414.m1IEE8bd075081@drugs.dv.isc.org> X-Google-Sender-Auth: 624f5be56ab92cd1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-security@freebsd.org Errors-To: owner-freebsd-security@freebsd.org Cc: Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 14:48:17 -0000 Hi, I would agree with Mark and Jim, this is a serious issue for enterprise servers. Yet another example where I would have wanted to see a more supportive response from the FreeBSD project members, like Robert Watson just did. This would benefit keeping a good relation with the business users. Thanks, Adrian Penisoara ROFUG / EnterpriseBSD On Feb 18, 2008 4:14 PM, Mark Andrews wrote: > > > Patient: Doctor, it hurts when I do this! > > > > Doctor: Don't do that... > > Did you actually bother to read his report? > > While his example is used "/", if the report is correct then you > just need to replace "/" with the path of any file system mount > point that is world writable like say "/tmp". > > Do you have /tmp mounted like this? > /dev/ad0s4e 507630 162050 304970 35% /tmp > > Have you tried using "/tmp" or some other suitable mount point > before slinging off with the old Doctor joke? > > Even if it is only "/", having the system die and not be recoverable > due to having a excessive number of files in "/" is a critical > error. I'm sure you have *never* accidently copied a set of files > to "/" in your life. Me, I know I've made that sort of mistake in > the past, and as I'm not perfect, I'm sure I'll make that sort of > mistake at some point in the future. I would however like the > machine not to fallover when I do make that mistake. > > Now why don't you be constructive and verify whether the report is > valid or not. I don't have a spare machine to test it on so I'm > not going to attempt it. > > Mark > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org > " > _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 14:48:28 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E41C216A41A for ; Mon, 18 Feb 2008 14:48:28 +0000 (UTC) (envelope-from ady@ady.ro) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.242]) by mx1.freebsd.org (Postfix) with ESMTP id A2E7513C46B for ; Mon, 18 Feb 2008 14:48:28 +0000 (UTC) (envelope-from ady@ady.ro) Received: by ag-out-0708.google.com with SMTP id 5so2550084agb.7 for ; Mon, 18 Feb 2008 06:48:28 -0800 (PST) Received: by 10.142.72.21 with SMTP id u21mr4365062wfa.82.1203345155884; Mon, 18 Feb 2008 06:32:35 -0800 (PST) Received: by 10.142.109.6 with HTTP; Mon, 18 Feb 2008 06:32:35 -0800 (PST) Message-ID: <78cb3d3f0802180632u1d38ec67i432052d9c77dd706@mail.gmail.com> Date: Mon, 18 Feb 2008 16:32:35 +0200 From: "Adrian Penisoara" Sender: ady@ady.ro To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org, freebsd-security@freebsd.org In-Reply-To: <200802181414.m1IEE8bd075081@drugs.dv.isc.org> MIME-Version: 1.0 References: <200802181414.m1IEE8bd075081@drugs.dv.isc.org> X-Google-Sender-Auth: 624f5be56ab92cd1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 14:48:29 -0000 Hi, I would agree with Mark and Jim, this is a serious issue for enterprise servers. Yet another example where I would have wanted to see a more supportive response from the FreeBSD project members, like Robert Watson just did. This would benefit keeping a good relation with the business users. Thanks, Adrian Penisoara ROFUG / EnterpriseBSD On Feb 18, 2008 4:14 PM, Mark Andrews wrote: > > > Patient: Doctor, it hurts when I do this! > > > > Doctor: Don't do that... > > Did you actually bother to read his report? > > While his example is used "/", if the report is correct then you > just need to replace "/" with the path of any file system mount > point that is world writable like say "/tmp". > > Do you have /tmp mounted like this? > /dev/ad0s4e 507630 162050 304970 35% /tmp > > Have you tried using "/tmp" or some other suitable mount point > before slinging off with the old Doctor joke? > > Even if it is only "/", having the system die and not be recoverable > due to having a excessive number of files in "/" is a critical > error. I'm sure you have *never* accidently copied a set of files > to "/" in your life. Me, I know I've made that sort of mistake in > the past, and as I'm not perfect, I'm sure I'll make that sort of > mistake at some point in the future. I would however like the > machine not to fallover when I do make that mistake. > > Now why don't you be constructive and verify whether the report is > valid or not. I don't have a spare machine to test it on so I'm > not going to attempt it. > > Mark > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org > " > From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 15:07:38 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFE1E16A418; Mon, 18 Feb 2008 15:07:38 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: from mail.radiokom.kr.ua (smtp.radiokom.kr.ua [193.17.174.11]) by mx1.freebsd.org (Postfix) with ESMTP id 45D7513C46E; Mon, 18 Feb 2008 15:07:37 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: by mail.radiokom.kr.ua (Postfix, from userid 1003) id 4E5F81D09A; Mon, 18 Feb 2008 17:07:36 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on shayba.homenet.kr.ua X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=6.0 tests=RATWR8_MESSID autolearn=disabled version=3.1.8 Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.radiokom.kr.ua (Postfix) with ESMTP id 6AADC1CFDA for ; Mon, 18 Feb 2008 17:07:23 +0200 (EET) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 8F5B619CEC; Mon, 18 Feb 2008 15:06:49 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 7D10316A481; Mon, 18 Feb 2008 15:06:49 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAA9516A49E for ; Mon, 18 Feb 2008 14:13:57 +0000 (UTC) (envelope-from speedtoys.racing@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.227]) by mx1.freebsd.org (Postfix) with ESMTP id 513E313C4D5 for ; Mon, 18 Feb 2008 14:13:56 +0000 (UTC) (envelope-from speedtoys.racing@gmail.com) Received: by qb-out-0506.google.com with SMTP id a10so1634968qbd.7 for ; Mon, 18 Feb 2008 06:13:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to:in-reply-to:content-type:x-mailer:mime-version:subject:content-transfer-encoding:date:cc; bh=9bLxeBN1YR5P3J2TSpLos4itvksm2Ux1AanE2niW2bg=; b=ZOyEdss95X3i8MhsBN78Bfix8JDkL7TFMi4gMJYZ9EUIZPkyEujwimahKNvfu/IqNOGN38fjogkwzGfq4ywdYDY+5ieboOoWspZCZgkd4yhDEKMEqn8uAfIAIkPBGw/xp91bDgLf4mcd+dThBCKcxBmeiUjytb45XtIO5EnwCgQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type:x-mailer:mime-version:subject:content-transfer-encoding:date:cc; b=K8WTuo+gYNAU8BscKx9WUJ+sYcbKzVrxD9L63QBa+ggoz5AZwSDBAoRJnt5kcjoqK1gwLS8RG0+1Dc3JWgBSId99lhXsVcrKKB1Tn4I9SrI4c70JG3jGYX7THSqyBt1KufWhilFPjRl9dlaefKk8JM6FiKRPfsv+v8FPT5B5/ms= Received: by 10.110.68.10 with SMTP id q10mr3339856tia.28.1203343083226; Mon, 18 Feb 2008 05:58:03 -0800 (PST) Received: from ?10.6.146.10? ( [166.193.195.177]) by mx.google.com with ESMTPS id h18sm10024404wxd.18.2008.02.18.05.57.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Feb 2008 05:58:01 -0800 (PST) References: <47B90868.7000900@electron-tube.net> <86odae5rgr.fsf@ds4.des.no> Message-Id: From: Speedtoys To: Kurt Buff In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes X-Mailer: iPhone Mail (4A93) Mime-Version: 1.0 (iPhone Mail 4A93) Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Feb 2008 08:57:46 -0500 X-Mailman-Approved-At: Mon, 18 Feb 2008 15:06:44 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-security@freebsd.org Errors-To: owner-freebsd-security@freebsd.org Cc: "freebsd-fs@freebsd.org" , =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , "FreeBSD-bugs@freebsd.org" , "freebsd-stable@freebsd.org" , "freebsd-security@freebsd.org" Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 15:07:39 -0000 Time for the idiot(proof) function call. Got brakes? =3D=3D=3D=3D=3D=3D 25hrs or one season with one pad set is possible. Save money and pit =20= time, compromise nothing. Ask how. TXT or Tone: 8414546712@txt.att.net http://www.speedtoys.com On Feb 18, 2008, at 8:27 AM, "Kurt Buff" wrote: > Patient: Doctor, it hurts when I do this! > > Doctor: Don't do that... > > On Feb 18, 2008 1:23 PM, Dag-Erling Sm=C3=B8rgrav wrote: >> Jim Bryant writes: >>> #include >>> #include >>> >>> int main(int argc, char **argv) { int i; char buf[1024]; bzero=20 >>> (buf, 1024); for(i =3D 0; i < 10000; i++) { sprintf(buf, "touch %s%=20= >>> 05d\n", argv[1], i); system((const char *)buf);} return(0);} >> >> Subject should be "how to take down a system [...] with three lines =20= >> of >> badly written C, provided you have root privileges already and are =20= >> too >> lazy to just dd if=3D/dev/zero of=3D/dev/ad0s1 count=3D100", which = would >> accomplish the job much faster. >> >> Purely in the interest of showing off, here is my version. It is 81 >> bytes shorter than yours, it is valid C99 with POSIX extensions =20 >> (yours >> is not), and it produces 11,450 files in about 0.2% of the time yours >> takes to produce 10,000. >> >> #include >> #define b(i,v) for(int v=3D48;v<127;++v){f[i]=3Dv; >> #define a(i) b(i,v##i) >> int main(void){char f[5]=3D{'/'};a(1)a(2)a(3)truncate(f,0);}}}} >> >> DES >> -- >> Dag-Erling Sm=C3=B8rgrav - des@des.no >> >> _______________________________________________ >> freebsd-security@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-security >> To unsubscribe, send any mail to = "freebsd-security-unsubscribe@freebsd.org=20 >> " >> > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to = "freebsd-security-unsubscribe@freebsd.org=20 > " > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 15:08:29 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FAFF16A473; Mon, 18 Feb 2008 15:08:29 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: from mail.radiokom.kr.ua (smtp.radiokom.kr.ua [193.17.174.11]) by mx1.freebsd.org (Postfix) with ESMTP id 18E5613C467; Mon, 18 Feb 2008 15:08:29 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: by mail.radiokom.kr.ua (Postfix, from userid 1003) id 3A8D41D151; Mon, 18 Feb 2008 17:08:28 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on shayba.homenet.kr.ua X-Spam-Level: X-Spam-Status: No, score=0.2 required=6.0 tests=MR_NOT_ATTRIBUTED_IP autolearn=disabled version=3.1.8 Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.radiokom.kr.ua (Postfix) with ESMTP id E35731D09A for ; Mon, 18 Feb 2008 17:08:23 +0200 (EET) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 322F36082E; Mon, 18 Feb 2008 15:06:59 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 1F6DB16A4E9; Mon, 18 Feb 2008 15:06:59 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54DAA16A41A; Mon, 18 Feb 2008 14:32:14 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 0407C13C4F7; Mon, 18 Feb 2008 14:32:13 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from scoo-longs-computer.local (74-92-209-69-Colorado.hfc.comcastbusiness.net [74.92.209.69] (may be forged)) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id m1IE9FaX012939; Mon, 18 Feb 2008 07:09:21 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <47B9918B.6010301@samsco.org> Date: Mon, 18 Feb 2008 07:09:15 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <47B90868.7000900@electron-tube.net> <86odae5rgr.fsf@ds4.des.no> <863arq5q14.fsf@ds4.des.no> In-Reply-To: <863arq5q14.fsf@ds4.des.no> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 18 Feb 2008 15:06:52 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-security@freebsd.org Errors-To: owner-freebsd-security@freebsd.org Cc: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, freebsd-stable@freebsd.org, FreeBSD-bugs@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 15:08:29 -0000 Dag-Erling Smørgrav wrote: > Dag-Erling Smørgrav writes: >> Purely in the interest of showing off, here is my version. It is 81 >> bytes shorter than yours, it is valid C99 with POSIX extensions (yours >> is not), and it produces 11,450 files in about 0.2% of the time yours >> takes to produce 10,000. >> >> #include >> #define b(i,v) for(int v=48;v<127;++v){f[i]=v; >> #define a(i) b(i,v##i) >> int main(void){char f[5]={'/'};a(1)a(2)a(3)truncate(f,0);}}}} > > Two bugs: > > 1) I forgot to include the correct version of the code > > 2) the version I had created a few files with '/' in their names; this > slightly nastier creates 10,648 files with only letters. > > #include > #define b(i,v)for(int v=65;v<87;){i[f]=v++; > #define a(i)b(i,v##i) > int main(void){char f[4]={47};a(1)a(2)a(3)truncate(f,0);}}}} > > DES This version also omits the constructive comments on the actual problem that the original poster identified. Scott _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 15:11:08 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F55D16A419; Mon, 18 Feb 2008 15:11:08 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: from mail.radiokom.kr.ua (smtp.radiokom.kr.ua [193.17.174.11]) by mx1.freebsd.org (Postfix) with ESMTP id BD87513C447; Mon, 18 Feb 2008 15:11:07 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: by mail.radiokom.kr.ua (Postfix, from userid 1003) id DD2031D190; Mon, 18 Feb 2008 17:11:06 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on shayba.homenet.kr.ua X-Spam-Level: X-Spam-Status: No, score=0.0 required=6.0 tests=none autolearn=disabled version=3.1.8 Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.radiokom.kr.ua (Postfix) with ESMTP id 2DE801D09A for ; Mon, 18 Feb 2008 17:11:02 +0200 (EET) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 0D77817E3D; Mon, 18 Feb 2008 15:07:21 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id DCF8316A4D5; Mon, 18 Feb 2008 15:07:21 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7D7316A417; Mon, 18 Feb 2008 14:35:36 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 99F3213C45B; Mon, 18 Feb 2008 14:35:35 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m1IDxmF0062860; Mon, 18 Feb 2008 20:59:48 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m1IDxmFb062859; Mon, 18 Feb 2008 20:59:48 +0700 (KRAT) (envelope-from eugen) Date: Mon, 18 Feb 2008 20:59:48 +0700 From: Eugene Grosbein To: des@des.no Message-ID: <20080218135948.GB62360@svzserv.kemerovo.su> References: <47B90868.7000900@electron-tube.net> <86odae5rgr.fsf@ds4.des.no> <863arq5q14.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <863arq5q14.fsf@ds4.des.no> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Mon, 18 Feb 2008 15:07:16 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-security@freebsd.org Errors-To: owner-freebsd-security@freebsd.org Cc: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, freebsd-stable@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 15:11:08 -0000 On Mon, Feb 18, 2008 at 02:53:59PM +0100, Dag-Erling Sm??rgrav wrote: > Two bugs: [skip] That's all very funny, but what about a panic? It it true that it's possible for non-root to bring a file system to not-mountable state? Eugene Grosbein _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 15:13:31 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C0B916A418; Mon, 18 Feb 2008 15:13:31 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 025F613C46A; Mon, 18 Feb 2008 15:13:30 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from scoo-longs-computer.local (74-92-209-69-Colorado.hfc.comcastbusiness.net [74.92.209.69] (may be forged)) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id m1IFDKtl013565; Mon, 18 Feb 2008 08:13:26 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <47B9A08F.4080703@samsco.org> Date: Mon, 18 Feb 2008 08:13:19 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7 MIME-Version: 1.0 To: Adrian Penisoara References: <200802181414.m1IEE8bd075081@drugs.dv.isc.org> <78cb3d3f0802180632u1d38ec67i432052d9c77dd706@mail.gmail.com> In-Reply-To: <78cb3d3f0802180632u1d38ec67i432052d9c77dd706@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.4 tests=none autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 15:13:31 -0000 Adrian Penisoara wrote: > Hi, > > I would agree with Mark and Jim, this is a serious issue for enterprise > servers. Yet another example where I would have wanted to see a more > supportive response from the FreeBSD project members, like Robert Watson > just did. This would benefit keeping a good relation with the business > users. > The responses from Dag-Erling was pretty much what I'd expect to see on a linux mailing list. Hopefully this filesystem issue gets some attention. Scott From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 15:30:06 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4125316A420; Mon, 18 Feb 2008 15:30:06 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: from mail.radiokom.kr.ua (smtp.radiokom.kr.ua [193.17.174.11]) by mx1.freebsd.org (Postfix) with ESMTP id BC4F313C4EE; Mon, 18 Feb 2008 15:30:05 +0000 (UTC) (envelope-from filter@mail.radiokom.kr.ua) Received: by mail.radiokom.kr.ua (Postfix, from userid 1003) id 02F0B1D215; Mon, 18 Feb 2008 17:30:02 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on shayba.homenet.kr.ua X-Spam-Level: X-Spam-Status: No, score=0.0 required=6.0 tests=none autolearn=disabled version=3.1.8 Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.radiokom.kr.ua (Postfix) with ESMTP id BD0BD1D187 for ; Mon, 18 Feb 2008 17:29:55 +0200 (EET) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E76445FCB3; Mon, 18 Feb 2008 15:29:10 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D390416A4EB; Mon, 18 Feb 2008 15:29:10 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BC1B16A420 for ; Mon, 18 Feb 2008 15:29:02 +0000 (UTC) (envelope-from phisher1@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.239]) by mx1.freebsd.org (Postfix) with ESMTP id F0CB513C448 for ; Mon, 18 Feb 2008 15:29:01 +0000 (UTC) (envelope-from phisher1@gmail.com) Received: by qb-out-0506.google.com with SMTP id a10so1687349qbd.7 for ; Mon, 18 Feb 2008 07:29:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=C1CPtFis2TVigXkW1JLW7KwnehKe6ffMD4EnW37XqqU=; b=DTj0KFzOweXJ8dyFSpL0mTA1swb4dBdUR+Zq7Xe4TPAq10bNEgfCKGZR+dkMkPK5GBSPuSZFX/vvteyaZmGBYAws5kiYwMuQRW/G6HOOtPVS/qZILjjIY9bVKdLQwPTX4sbJf07y8R33N2x47VFN3Yz0TtvaabEdyaqKyWGqLMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=i0GtlivR/YwwY3zY4XVY43RfbVZG++mLScK1pNeT5NQCTnv/Cjd8/3gRkDEDJ2mkySrp/jE5zsmNHE5DPTE96RcEnxbxnOX7ese9xQZNpW+eiKEQLiEBauHNS7dtVZaqFqG6/0gTrHJOna0mte0c3vFGW/EPa50tENj8y0BXhSw= Received: by 10.114.37.1 with SMTP id k1mr2931815wak.6.1203347670178; Mon, 18 Feb 2008 07:14:30 -0800 (PST) Received: by 10.114.109.15 with HTTP; Mon, 18 Feb 2008 07:14:30 -0800 (PST) Message-ID: <291ddc4f0802180714g3d326626v9d9b767a61232cec@mail.gmail.com> Date: Mon, 18 Feb 2008 09:14:30 -0600 From: "Daniel Corrigan" To: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org In-Reply-To: <47B90868.7000900@electron-tube.net> MIME-Version: 1.0 References: <47B90868.7000900@electron-tube.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-security@freebsd.org Errors-To: owner-freebsd-security@freebsd.org Cc: Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 15:30:06 -0000 Since this was released to a public mailing list, I can only assume some less than nice user will attempt this. The only top level file system I have that can be written to by normal users is /tmp Should clear_tmp_enable="YES" in /etc/rc.conf prevent this from causing harm? Dan On Feb 17, 2008 10:24 PM, Jim Bryant wrote: > One line summary: > Too many files in a top-level UFS-2 filesystem directory will cause > a panic on mount. > > Kern/Critical/High Priority/SW-Bug > > Which FreeBSD Release You Are Using: > 6.3-STABLE > > Environment (output of "uname -a" on the problem machine): > FreeBSD wahoo.sd67dfl.org 6.3-STABLE FreeBSD 6.3-STABLE #0: Sun Feb > 10 21:13:39 CST 2008 > jbryant@wahoo.sd67dfl.org:/usr/obj/usr/src/sys/WAHOO-SMP i386 > > Note: I just cvsupped earlier, and no changes have been put into > cvsup that would fix this problem. > > Full Description: > I was doing a reorganization of my filesystems, and since I do > offline installs, I keep a local distfiles collection (or did until > yesterday when this happened), and in the process, put all of the > distfiles on their own filesystem to be mounted under > /usr/ports/distfiles. > > All was fine until I rebooted. > > On rebooting, I got a page fault panic on mount of the new distfiles > filesystem. > > i booted again, got it again, booted again this time into single-user, > and did a fsck on the filesystem, and it only showed as being "dirty", > but otherwise had no problems in the eyes of fsck. booted again, > instant panic. > > i booted an older 6.2 CD and mounted the filesystem fine. i then put > that filesystem the way it was by mkdir'ing a distfiles dir and mv'ing > everything into it, but on reboot it still paniced on mount. > > only a newfs was able to enable the filesystem to be mounted. > > today i did further research, thinking it had to do with the number of > files in the top-level filesystem directory, and found that to be true. > the short c program in the next section (how to repeat the problem) > contains this. > > a second test shows that, after a newfs, if this done in any > subdirectory of that filesystem, the panic is averted, and all is well. > apparently this bug only effects top-level directories of a UFS2 > filesystem. > > I have not attempted this to a non-UFS2 filesystem. > > IMHO, a security advisory should be released, since any user with write > access to ANY top level directory of ANY mounted filesystem (most > systems have /tmp as a world writable top level filesystem directory) > can create a panic situation requiring a newfs of the said filesystem. > A malicious user with root access can do this to /. Either way, on > boot, or any attempt to mount said filesystem on a running system, will > cause a panic, which of course will cause an unbootable system on reboot. > > How to repeat the problem: > Compile and run the following as instructed: > > #include > #include > > int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, > 1024); for(i = 0; i < 10000; i++) { sprintf(buf, "touch %s%05d\n", > argv[1], i); system((const char *)buf);} return(0);} > > /* pass a top-level mountpoint directory name of a mounted filesystem, > with a trailing slash to the above as argv[1], and run. > > This will create 10,000 zero-length files in the specified directory. > > umount that filesystem. > > perform a shitload of sync's to make sure everything outstanding is > flushed to disk on all filesystems. > > mount the target filesystem (preferably from a vty or serial console to > catch the messages when it panics, which it will as soon as the mount is > attempted). > */ > > Fix to the problem if known: > newfs(8) > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org > " > _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 15:30:16 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0743816A4D5 for ; Mon, 18 Feb 2008 15:30:16 +0000 (UTC) (envelope-from phisher1@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.224]) by mx1.freebsd.org (Postfix) with ESMTP id 9D09113C4D1 for ; Mon, 18 Feb 2008 15:30:15 +0000 (UTC) (envelope-from phisher1@gmail.com) Received: by qb-out-0506.google.com with SMTP id a10so1688143qbd.7 for ; Mon, 18 Feb 2008 07:30:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=C1CPtFis2TVigXkW1JLW7KwnehKe6ffMD4EnW37XqqU=; b=DTj0KFzOweXJ8dyFSpL0mTA1swb4dBdUR+Zq7Xe4TPAq10bNEgfCKGZR+dkMkPK5GBSPuSZFX/vvteyaZmGBYAws5kiYwMuQRW/G6HOOtPVS/qZILjjIY9bVKdLQwPTX4sbJf07y8R33N2x47VFN3Yz0TtvaabEdyaqKyWGqLMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=i0GtlivR/YwwY3zY4XVY43RfbVZG++mLScK1pNeT5NQCTnv/Cjd8/3gRkDEDJ2mkySrp/jE5zsmNHE5DPTE96RcEnxbxnOX7ese9xQZNpW+eiKEQLiEBauHNS7dtVZaqFqG6/0gTrHJOna0mte0c3vFGW/EPa50tENj8y0BXhSw= Received: by 10.114.37.1 with SMTP id k1mr2931815wak.6.1203347670178; Mon, 18 Feb 2008 07:14:30 -0800 (PST) Received: by 10.114.109.15 with HTTP; Mon, 18 Feb 2008 07:14:30 -0800 (PST) Message-ID: <291ddc4f0802180714g3d326626v9d9b767a61232cec@mail.gmail.com> Date: Mon, 18 Feb 2008 09:14:30 -0600 From: "Daniel Corrigan" To: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org In-Reply-To: <47B90868.7000900@electron-tube.net> MIME-Version: 1.0 References: <47B90868.7000900@electron-tube.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 15:30:16 -0000 Since this was released to a public mailing list, I can only assume some less than nice user will attempt this. The only top level file system I have that can be written to by normal users is /tmp Should clear_tmp_enable="YES" in /etc/rc.conf prevent this from causing harm? Dan On Feb 17, 2008 10:24 PM, Jim Bryant wrote: > One line summary: > Too many files in a top-level UFS-2 filesystem directory will cause > a panic on mount. > > Kern/Critical/High Priority/SW-Bug > > Which FreeBSD Release You Are Using: > 6.3-STABLE > > Environment (output of "uname -a" on the problem machine): > FreeBSD wahoo.sd67dfl.org 6.3-STABLE FreeBSD 6.3-STABLE #0: Sun Feb > 10 21:13:39 CST 2008 > jbryant@wahoo.sd67dfl.org:/usr/obj/usr/src/sys/WAHOO-SMP i386 > > Note: I just cvsupped earlier, and no changes have been put into > cvsup that would fix this problem. > > Full Description: > I was doing a reorganization of my filesystems, and since I do > offline installs, I keep a local distfiles collection (or did until > yesterday when this happened), and in the process, put all of the > distfiles on their own filesystem to be mounted under > /usr/ports/distfiles. > > All was fine until I rebooted. > > On rebooting, I got a page fault panic on mount of the new distfiles > filesystem. > > i booted again, got it again, booted again this time into single-user, > and did a fsck on the filesystem, and it only showed as being "dirty", > but otherwise had no problems in the eyes of fsck. booted again, > instant panic. > > i booted an older 6.2 CD and mounted the filesystem fine. i then put > that filesystem the way it was by mkdir'ing a distfiles dir and mv'ing > everything into it, but on reboot it still paniced on mount. > > only a newfs was able to enable the filesystem to be mounted. > > today i did further research, thinking it had to do with the number of > files in the top-level filesystem directory, and found that to be true. > the short c program in the next section (how to repeat the problem) > contains this. > > a second test shows that, after a newfs, if this done in any > subdirectory of that filesystem, the panic is averted, and all is well. > apparently this bug only effects top-level directories of a UFS2 > filesystem. > > I have not attempted this to a non-UFS2 filesystem. > > IMHO, a security advisory should be released, since any user with write > access to ANY top level directory of ANY mounted filesystem (most > systems have /tmp as a world writable top level filesystem directory) > can create a panic situation requiring a newfs of the said filesystem. > A malicious user with root access can do this to /. Either way, on > boot, or any attempt to mount said filesystem on a running system, will > cause a panic, which of course will cause an unbootable system on reboot. > > How to repeat the problem: > Compile and run the following as instructed: > > #include > #include > > int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, > 1024); for(i = 0; i < 10000; i++) { sprintf(buf, "touch %s%05d\n", > argv[1], i); system((const char *)buf);} return(0);} > > /* pass a top-level mountpoint directory name of a mounted filesystem, > with a trailing slash to the above as argv[1], and run. > > This will create 10,000 zero-length files in the specified directory. > > umount that filesystem. > > perform a shitload of sync's to make sure everything outstanding is > flushed to disk on all filesystems. > > mount the target filesystem (preferably from a vty or serial console to > catch the messages when it panics, which it will as soon as the mount is > attempted). > */ > > Fix to the problem if known: > newfs(8) > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org > " > From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 16:29:03 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F6BD16A46C for ; Mon, 18 Feb 2008 16:29:03 +0000 (UTC) (envelope-from admin@su29.net) Received: from aliska.alo.ru (aliska.alo.ru [80.251.131.12]) by mx1.freebsd.org (Postfix) with ESMTP id A8B7613C4D1 for ; Mon, 18 Feb 2008 16:29:02 +0000 (UTC) (envelope-from admin@su29.net) Received: from aliska (aliska.alo.ru [80.251.131.12]) by aliska.alo.ru (Postfix) with SMTP id DE77F24C9EC for ; Mon, 18 Feb 2008 18:56:55 +0300 (MSK) Received: from ws.su29.net (ppp85-141-155-76.pppoe.mtu-net.ru [85.141.155.76]) by aliska.alo.ru (Postfix) with ESMTP id A181124CC11; Mon, 18 Feb 2008 18:56:54 +0300 (MSK) Message-ID: <47B9AAB3.4090407@su29.net> Date: Mon, 18 Feb 2008 18:56:35 +0300 From: "Alexander V. Chernikov" Organization: AlmazTelecom User-Agent: Thunderbird 2.0.0.9 (X11/20080210) MIME-Version: 1.0 To: Daniel Corrigan References: <47B90868.7000900@electron-tube.net> <291ddc4f0802180714g3d326626v9d9b767a61232cec@mail.gmail.com> In-Reply-To: <291ddc4f0802180714g3d326626v9d9b767a61232cec@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: admin@su29.net List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 16:29:03 -0000 Daniel Corrigan wrote: > Since this was released to a public mailing list, I can only assume some > less than nice user will attempt this. > The only top level file system I have that can be written to by normal users > is /tmp > > Should clear_tmp_enable="YES" in /etc/rc.conf prevent this from causing > harm? /etc/rc.d/cleartmp does /tmp clearing only at startup, after file systems are mounted. > > Dan > > On Feb 17, 2008 10:24 PM, Jim Bryant wrote: > >> One line summary: >> Too many files in a top-level UFS-2 filesystem directory will cause >> a panic on mount. >> >> Kern/Critical/High Priority/SW-Bug >> >> Which FreeBSD Release You Are Using: >> 6.3-STABLE >> >> Environment (output of "uname -a" on the problem machine): >> FreeBSD wahoo.sd67dfl.org 6.3-STABLE FreeBSD 6.3-STABLE #0: Sun Feb >> 10 21:13:39 CST 2008 >> jbryant@wahoo.sd67dfl.org:/usr/obj/usr/src/sys/WAHOO-SMP i386 >> >> Note: I just cvsupped earlier, and no changes have been put into >> cvsup that would fix this problem. >> >> Full Description: >> I was doing a reorganization of my filesystems, and since I do >> offline installs, I keep a local distfiles collection (or did until >> yesterday when this happened), and in the process, put all of the >> distfiles on their own filesystem to be mounted under >> /usr/ports/distfiles. >> >> All was fine until I rebooted. >> >> On rebooting, I got a page fault panic on mount of the new distfiles >> filesystem. >> >> i booted again, got it again, booted again this time into single-user, >> and did a fsck on the filesystem, and it only showed as being "dirty", >> but otherwise had no problems in the eyes of fsck. booted again, >> instant panic. >> >> i booted an older 6.2 CD and mounted the filesystem fine. i then put >> that filesystem the way it was by mkdir'ing a distfiles dir and mv'ing >> everything into it, but on reboot it still paniced on mount. >> >> only a newfs was able to enable the filesystem to be mounted. >> >> today i did further research, thinking it had to do with the number of >> files in the top-level filesystem directory, and found that to be true. >> the short c program in the next section (how to repeat the problem) >> contains this. >> >> a second test shows that, after a newfs, if this done in any >> subdirectory of that filesystem, the panic is averted, and all is well. >> apparently this bug only effects top-level directories of a UFS2 >> filesystem. >> >> I have not attempted this to a non-UFS2 filesystem. >> >> IMHO, a security advisory should be released, since any user with write >> access to ANY top level directory of ANY mounted filesystem (most >> systems have /tmp as a world writable top level filesystem directory) >> can create a panic situation requiring a newfs of the said filesystem. >> A malicious user with root access can do this to /. Either way, on >> boot, or any attempt to mount said filesystem on a running system, will >> cause a panic, which of course will cause an unbootable system on reboot. >> >> How to repeat the problem: >> Compile and run the following as instructed: >> >> #include >> #include >> >> int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, >> 1024); for(i = 0; i < 10000; i++) { sprintf(buf, "touch %s%05d\n", >> argv[1], i); system((const char *)buf);} return(0);} >> >> /* pass a top-level mountpoint directory name of a mounted filesystem, >> with a trailing slash to the above as argv[1], and run. >> >> This will create 10,000 zero-length files in the specified directory. >> >> umount that filesystem. >> >> perform a shitload of sync's to make sure everything outstanding is >> flushed to disk on all filesystems. >> >> mount the target filesystem (preferably from a vty or serial console to >> catch the messages when it panics, which it will as soon as the mount is >> attempted). >> */ >> >> Fix to the problem if known: >> newfs(8) >> >> _______________________________________________ >> freebsd-security@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-security >> To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org >> " >> > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 16:30:45 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09F6E16A52C for ; Mon, 18 Feb 2008 16:30:45 +0000 (UTC) (envelope-from steve@pepcross.com) Received: from smtp-out2.blueyonder.co.uk (smtp-out2.blueyonder.co.uk [195.188.213.5]) by mx1.freebsd.org (Postfix) with ESMTP id A3EC613C461 for ; Mon, 18 Feb 2008 16:30:44 +0000 (UTC) (envelope-from steve@pepcross.com) Received: from [172.23.170.143] (helo=anti-virus02-10) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1JR8Tr-0000lI-Pa for freebsd-fs@freebsd.org; Mon, 18 Feb 2008 16:04:35 +0000 Received: from [82.32.9.178] (helo=pepcross.com) by asmtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1JR8Tr-0001JL-AL for freebsd-fs@freebsd.org; Mon, 18 Feb 2008 16:04:35 +0000 Received: by pepcross.com (sSMTP sendmail emulation); Mon, 18 Feb 2008 16:04:27 +0000 From: "Steve Roome" Date: Mon, 18 Feb 2008 16:04:27 +0000 To: freebsd-fs@freebsd.org Message-ID: <20080218160427.GA3700@zebedee.internal.pepcross.com> References: <200802181414.m1IEE8bd075081@drugs.dv.isc.org> <78cb3d3f0802180632u1d38ec67i432052d9c77dd706@mail.gmail.com> <47B9A08F.4080703@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47B9A08F.4080703@samsco.org> User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 16:30:45 -0000 On Mon, Feb 18, 2008 at 08:13:19AM -0700, Scott Long wrote: > Adrian Penisoara wrote: >> Hi, >> I would agree with Mark and Jim, this is a serious issue for enterprise >> servers. Yet another example where I would have wanted to see a more >> supportive response from the FreeBSD project members, like Robert Watson >> just did. This would benefit keeping a good relation with the business >> users. > > The responses from Dag-Erling was pretty much what I'd expect to see on > a linux mailing list. Hopefully this filesystem issue gets some > attention. Scott... err... so that's praise for des ? ;) Still, instead of being too disctracted by "social issues". Does anyone know if creating lots of files at the root breaks UFS2 without softupdates enabled and does this same thing affect any other filesystems ? As to the social bit... We ought to have something in the list faq and charter about how you should expect at least one "odd" comment from someone every time you post to the list. http://www.freebsd.org/doc/en_US.ISO8859-1/articles/mailing-list-faq/ Besides, this is all "publicity" (as in, "no such thing as bad publicity") for the original issue and the more noise the more folks will see it and so on. Maybe des just did FreeBSD a huge favour by making more people follow the list, worry about it, test it and be sure it's fixed in the future ? Steve Roome P.S. Personally I thought des' response was hilarious! But I say that with the greatest amount of respect for the original posters brilliant problem description. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 17:21:24 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCCA316A421; Mon, 18 Feb 2008 17:21:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id B462913C4D3; Mon, 18 Feb 2008 17:21:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 2541D46B45; Mon, 18 Feb 2008 12:21:24 -0500 (EST) Date: Mon, 18 Feb 2008 17:21:24 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jim Bryant In-Reply-To: <20080218142004.O49202@fledge.watson.org> Message-ID: <20080218171841.O49202@fledge.watson.org> References: <47B90868.7000900@electron-tube.net> <47B91080.9010109@electron-tube.net> <20080218142004.O49202@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 17:21:25 -0000 On Mon, 18 Feb 2008, Robert Watson wrote: > Hopefully this bug will get resolved shortly, and then we can evaluate if an > errata notice is necessary. FYI, I have been unable, thus far, to reproduce it with 150,000 entries in the root of a test file system on an 8.x kernel. I'm not set up to test 6.x and 7.x currently, and have other obligations tht will prevent me from setting up 6.x and 7.x test images for a few days. If people who can reproduce this problem could send kernel stack traces (etc) as a follow-up to the PR, that would be most helpful. Right now it's sparse on actual debugging data. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 17:27:35 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21DC816A468; Mon, 18 Feb 2008 17:27:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id CB98F13C46A; Mon, 18 Feb 2008 17:27:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 7326646B66; Mon, 18 Feb 2008 12:27:34 -0500 (EST) Date: Mon, 18 Feb 2008 17:27:34 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Daniel Corrigan In-Reply-To: <291ddc4f0802180714g3d326626v9d9b767a61232cec@mail.gmail.com> Message-ID: <20080218172503.G49202@fledge.watson.org> References: <47B90868.7000900@electron-tube.net> <291ddc4f0802180714g3d326626v9d9b767a61232cec@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 17:27:35 -0000 On Mon, 18 Feb 2008, Daniel Corrigan wrote: > Since this was released to a public mailing list, I can only assume some > less than nice user will attempt this. The only top level file system I have > that can be written to by normal users is /tmp > > Should clear_tmp_enable="YES" in /etc/rc.conf prevent this from causing > harm? There are a few things that come to mind, depending on how reproduceable this is. If we think it's purely a property of the number of files in the root directory (I think this is an unlikely single cause -- it might have to do with the size of the directory, or such, which loosely corresponds to it), then you can limit the number of inodes in the file system at all. The example code in the report suggests 10,000 entries does the trick. You could create a /tmp limited to, say, 5000 entries. You can also use quotas to limit the number of inodes allocated by any one user but leave the file system unmodified, as while modifying the file system may be OK for /tmp, it's probably less OK for /home. Robert N M Watson Computer Laboratory University of Cambridge > > Dan > > On Feb 17, 2008 10:24 PM, Jim Bryant wrote: > >> One line summary: >> Too many files in a top-level UFS-2 filesystem directory will cause >> a panic on mount. >> >> Kern/Critical/High Priority/SW-Bug >> >> Which FreeBSD Release You Are Using: >> 6.3-STABLE >> >> Environment (output of "uname -a" on the problem machine): >> FreeBSD wahoo.sd67dfl.org 6.3-STABLE FreeBSD 6.3-STABLE #0: Sun Feb >> 10 21:13:39 CST 2008 >> jbryant@wahoo.sd67dfl.org:/usr/obj/usr/src/sys/WAHOO-SMP i386 >> >> Note: I just cvsupped earlier, and no changes have been put into >> cvsup that would fix this problem. >> >> Full Description: >> I was doing a reorganization of my filesystems, and since I do >> offline installs, I keep a local distfiles collection (or did until >> yesterday when this happened), and in the process, put all of the >> distfiles on their own filesystem to be mounted under >> /usr/ports/distfiles. >> >> All was fine until I rebooted. >> >> On rebooting, I got a page fault panic on mount of the new distfiles >> filesystem. >> >> i booted again, got it again, booted again this time into single-user, >> and did a fsck on the filesystem, and it only showed as being "dirty", >> but otherwise had no problems in the eyes of fsck. booted again, >> instant panic. >> >> i booted an older 6.2 CD and mounted the filesystem fine. i then put >> that filesystem the way it was by mkdir'ing a distfiles dir and mv'ing >> everything into it, but on reboot it still paniced on mount. >> >> only a newfs was able to enable the filesystem to be mounted. >> >> today i did further research, thinking it had to do with the number of >> files in the top-level filesystem directory, and found that to be true. >> the short c program in the next section (how to repeat the problem) >> contains this. >> >> a second test shows that, after a newfs, if this done in any >> subdirectory of that filesystem, the panic is averted, and all is well. >> apparently this bug only effects top-level directories of a UFS2 >> filesystem. >> >> I have not attempted this to a non-UFS2 filesystem. >> >> IMHO, a security advisory should be released, since any user with write >> access to ANY top level directory of ANY mounted filesystem (most >> systems have /tmp as a world writable top level filesystem directory) >> can create a panic situation requiring a newfs of the said filesystem. >> A malicious user with root access can do this to /. Either way, on >> boot, or any attempt to mount said filesystem on a running system, will >> cause a panic, which of course will cause an unbootable system on reboot. >> >> How to repeat the problem: >> Compile and run the following as instructed: >> >> #include >> #include >> >> int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, >> 1024); for(i = 0; i < 10000; i++) { sprintf(buf, "touch %s%05d\n", >> argv[1], i); system((const char *)buf);} return(0);} >> >> /* pass a top-level mountpoint directory name of a mounted filesystem, >> with a trailing slash to the above as argv[1], and run. >> >> This will create 10,000 zero-length files in the specified directory. >> >> umount that filesystem. >> >> perform a shitload of sync's to make sure everything outstanding is >> flushed to disk on all filesystems. >> >> mount the target filesystem (preferably from a vty or serial console to >> catch the messages when it panics, which it will as soon as the mount is >> attempted). >> */ >> >> Fix to the problem if known: >> newfs(8) >> >> _______________________________________________ >> freebsd-security@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-security >> To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org >> " >> > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 18:09:32 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E3B616A41B for ; Mon, 18 Feb 2008 18:09:32 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id C13F713C45E for ; Mon, 18 Feb 2008 18:09:31 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A7956.dip.t-dialin.net [84.154.121.86]) (authenticated bits=0) by flat.berklix.org (8.13.8/8.13.8) with ESMTP id m1II9Dti065515; Mon, 18 Feb 2008 19:09:14 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id m1IIBh1S017519; Mon, 18 Feb 2008 19:11:43 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id m1IIBX0E025281; Mon, 18 Feb 2008 19:11:38 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200802181811.m1IIBX0E025281@fire.js.berklix.net> To: Jim Bryant , freebsd-fs@freebsd.org In-reply-to: <20080218142004.O49202@fledge.watson.org> References: <47B90868.7000900@electron-tube.net> <47B91080.9010109@electron-tube.net> <20080218142004.O49202@fledge.watson.org> Comments: In-reply-to Robert Watson message dated "Mon, 18 Feb 2008 14:25:48 +0000." Date: Mon, 18 Feb 2008 19:11:33 +0100 From: "Julian H. Stacey" Cc: Robert Watson Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 18:09:32 -0000 Jim Bryant, please note for future, that (As well as Robert W. pointing out a quiet tip off to securiy team is sometimes better than broadcasting to a list), a broadcast to 4 FreeBSD lists eg FreeBSD-bugs@freebsd.org freebsd-fs@freebsd.org freebsd-security@freebsd.org freebsd-stable@freebsd.org breaks FreeBSD rules : http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL C.1.3 List Charters ... Point 2 ... No posting should be made to more than 2 mailing lists, and only to 2 when a clear and obvious need .... PS This posted to one list: freebsd-fs@freebsd.org Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 18:13:33 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E0C416A477; Mon, 18 Feb 2008 18:13:33 +0000 (UTC) (envelope-from lambert@lambertfam.org) Received: from sysmon.tcworks.net (sysmon.tcworks.net [65.66.76.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6580713C45B; Mon, 18 Feb 2008 18:13:33 +0000 (UTC) (envelope-from lambert@lambertfam.org) Received: from sysmon.tcworks.net (localhost [127.0.0.1]) by sysmon.tcworks.net (8.13.1/8.13.1) with ESMTP id m1IHYeTD001189; Mon, 18 Feb 2008 11:34:40 -0600 (CST) (envelope-from lambert@lambertfam.org) Received: (from lambert@localhost) by sysmon.tcworks.net (8.13.1/8.13.1/Submit) id m1IHYe95001188; Mon, 18 Feb 2008 11:34:40 -0600 (CST) (envelope-from lambert@lambertfam.org) X-Authentication-Warning: sysmon.tcworks.net: lambert set sender to lambert@lambertfam.org using -f Date: Mon, 18 Feb 2008 11:34:40 -0600 From: Scott Lambert To: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org Message-ID: <20080218173439.GA40800@sysmon.tcworks.net> Mail-Followup-To: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org References: <47B90868.7000900@electron-tube.net> <291ddc4f0802180714g3d326626v9d9b767a61232cec@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <291ddc4f0802180714g3d326626v9d9b767a61232cec@mail.gmail.com> User-Agent: Mutt/1.4.2.2i Cc: Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 18:13:33 -0000 On Mon, Feb 18, 2008 at 09:14:30AM -0600, Daniel Corrigan wrote: > Since this was released to a public mailing list, I can only assume > some less than nice user will attempt this. The only top level file > system I have that can be written to by normal users is /tmp > > Should clear_tmp_enable="YES" in /etc/rc.conf prevent this from > causing harm? Probably not. But an inode quota might, if your users can deal with having less than 10000 inodes - (what is supposed to be in the root of such file systems). It would at least make it more difficult for one rogue user to hurt you. Perhaps an /usr/local/etc/rc.d script could look for problems such as this in the stop process. Or one could simply remount the /tmp disk to /data and make a symlink from /tmp to /data/tmp. It seems like there should be several possible workarounds. -- Scott Lambert KC5MLE Unix SysAdmin lambert@lambertfam.org From owner-freebsd-fs@FreeBSD.ORG Mon Feb 18 20:35:50 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C57F16A468; Mon, 18 Feb 2008 20:35:50 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6A87D13C468; Mon, 18 Feb 2008 20:35:43 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47B9EC1D.6060606@FreeBSD.org> Date: Mon, 18 Feb 2008 21:35:41 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Eugene Grosbein References: <47B90868.7000900@electron-tube.net> <86odae5rgr.fsf@ds4.des.no> <863arq5q14.fsf@ds4.des.no> <20080218135948.GB62360@svzserv.kemerovo.su> In-Reply-To: <20080218135948.GB62360@svzserv.kemerovo.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, des@des.no, freebsd-stable@freebsd.org, freebsd-security@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 20:35:50 -0000 Eugene Grosbein wrote: > On Mon, Feb 18, 2008 at 02:53:59PM +0100, Dag-Erling Sm??rgrav wrote: > >> Two bugs: > > [skip] > > That's all very funny, but what about a panic? > > It it true that it's possible for non-root to bring a file system > to not-mountable state? The issue appears to be more subtle than claimed, because no-one else reports being able to reproduce it yet. Kris From owner-freebsd-fs@FreeBSD.ORG Tue Feb 19 00:10:33 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6019C16A41B; Tue, 19 Feb 2008 00:10:33 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 046C313C457; Tue, 19 Feb 2008 00:10:32 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: by mail.geek.sh (Postfix, from userid 1000) id 74E7724D2C; Tue, 19 Feb 2008 01:39:04 +0200 (SAST) Date: Tue, 19 Feb 2008 01:39:04 +0200 From: Aragon Gouveia To: Jim Bryant Message-ID: <20080218233904.GA91321@phat.za.net> References: <47B90868.7000900@electron-tube.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47B90868.7000900@electron-tube.net> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 4.10-RELEASE-p2 i386 Cc: freebsd-fs@freebsd.org, FreeBSD-bugs@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 00:10:33 -0000 Hi. Have you used growfs on your filesystem at any point in time? The only time I've experienced Strange Things Happening with UFS filesystems in 6.x was after (possibly mis)using growfs on them. Regards, Aragon | By Jim Bryant | [ 2008-02-18 06:39 +0200 ] > One line summary: > Too many files in a top-level UFS-2 filesystem directory will cause > a panic on mount. [snip] From owner-freebsd-fs@FreeBSD.ORG Tue Feb 19 02:17:40 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 570C616A418 for ; Tue, 19 Feb 2008 02:17:40 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.245]) by mx1.freebsd.org (Postfix) with ESMTP id 0F42913C461 for ; Tue, 19 Feb 2008 02:17:39 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by ag-out-0708.google.com with SMTP id 5so2994796agb.7 for ; Mon, 18 Feb 2008 18:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=LDOCXQnUVv9TPPuAOG+kRE2uARyM7BS0dSu+BU3+kvY=; b=bKsKPeSEPPYwJsfjy5Df4wPwj0HEZakKNdC2I8mD/ppQZkDXgUjYfxvZsS5j2kzgXhW2/4q6416UEG7zYuu47Opa04oEB7wW3GyvGJKbVaev2p3ACP/r9qjJ75G3Ww1/lUKojjZ66GYBKIhbxCpr7jpPV1BWhrUUwwY82wEcHN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=vQdWNSdN6kMh5cNfzLm4zD2M31jF2GoW6GhsqfWO/C9f5oyge8NBhDZNSKCGFZAelGCILlQxI3bEtAMjJwP/r52bh0xStsz0uo1DIbZqlr2Rw8HWqud8WTHfxrg79IImKyqi7kZ5gJgJnTmyhm9x0lUIGYwe0I0G7iga87BIxD0= Received: by 10.100.210.9 with SMTP id i9mr12949610ang.40.1203386502590; Mon, 18 Feb 2008 18:01:42 -0800 (PST) Received: from ?10.0.3.231? ( [70.111.176.151]) by mx.google.com with ESMTPS id d29sm12618930and.28.2008.02.18.18.01.39 (version=SSLv3 cipher=RC4-MD5); Mon, 18 Feb 2008 18:01:41 -0800 (PST) From: "Alexandre \"Sunny\" Kovalenko" To: Robert Watson In-Reply-To: <20080218171841.O49202@fledge.watson.org> References: <47B90868.7000900@electron-tube.net> <47B91080.9010109@electron-tube.net> <20080218142004.O49202@fledge.watson.org> <20080218171841.O49202@fledge.watson.org> Content-Type: text/plain; charset=utf-8 Date: Mon, 18 Feb 2008 21:01:13 -0500 Message-Id: <1203386473.19985.14.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, freebsd-stable@freebsd.org, FreeBSD-bugs@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 02:17:40 -0000 On Mon, 2008-02-18 at 17:21 +0000, Robert Watson wrote: > On Mon, 18 Feb 2008, Robert Watson wrote: > > > Hopefully this bug will get resolved shortly, and then we can evaluate if an > > errata notice is necessary. > > FYI, I have been unable, thus far, to reproduce it with 150,000 entries in the > root of a test file system on an 8.x kernel. I'm not set up to test 6.x and > 7.x currently, and have other obligations tht will prevent me from setting up > 6.x and 7.x test images for a few days. FWIW: I can not reproduce this on the 7.0-RC2: twinhead# umount /usr/ports/distfiles twinhead# sync twinhead# sync twinhead# sync twinhead# sync twinhead# mount /usr/ports/distfiles twinhead# df -k Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/da0s1a 8119416 4714312 2755552 63% / devfs 1 1 0 100% /dev /dev/da0s3d 7054514 1032194 5457960 16% /home /dev/stripe/shared 103288206 66041510 28983640 69% /SHARED /dev/stripe/S0 378425950 116115180 232036694 33% /STORAGE procfs 4 4 0 100% /proc /dev/ad4s2 47298314 4314412 39200038 10% /usr/ports/distfiles twinhead# cd /usr/ports/distfiles twinhead# ls | egrep "^[0-9]" | wc -l 10000 twinhead# ls | wc -l 10673 twinhead# uname -a FreeBSD twinhead.rabbitslawn.verizon.net 7.0-RC2 FreeBSD 7.0-RC2 #0: Sat Feb 16 08:44:12 EST 2008 root@twinhead.rabbitslawn.verizon.net:/usr/obj/usr/src/sys/TWINHEAD i386 If this makes any difference, this is SMP machine running SMP kernel. > > If people who can reproduce this problem could send kernel stack traces (etc) > as a follow-up to the PR, that would be most helpful. Right now it's sparse > on actual debugging data. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Alexandre "Sunny" Kovalenko (ОлекÑандр Коваленко) From owner-freebsd-fs@FreeBSD.ORG Tue Feb 19 02:38:40 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A819516A421; Tue, 19 Feb 2008 02:38:40 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 88C0D13C469; Tue, 19 Feb 2008 02:38:40 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.13.7) with ESMTP id m1J2QHgb093024; Mon, 18 Feb 2008 18:26:17 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m1J2QHNI093023; Mon, 18 Feb 2008 18:26:17 -0800 (PST) Date: Mon, 18 Feb 2008 18:26:17 -0800 (PST) From: Matthew Dillon Message-Id: <200802190226.m1J2QHNI093023@apollo.backplane.com> To: Jim Bryant References: <47B90868.7000900@electron-tube.net> <86odae5rgr.fsf@ds4.des.no> <863arq5q14.fsf@ds4.des.no> <20080218135948.GB62360@svzserv.kemerovo.su> <47B9EC1D.6060606@FreeBSD.org> Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 02:38:40 -0000 Jim's original report seemed to indicate that the filesystem paniced on mount even after repeated fsck's. That implies that Jim has a filesystem image that panics on mount. Maybe Jim can make that image available and a few people can see if downloading and mounting it reproduces the problem. It would narrow things down anyhow. Also, I didn't see a system backtrace anywhere. If it paniced, where did it panic? The first thing that came to my mind was the dirhash code, but simply mounting a filesystem doesn't scan the mount point directory at all, except possibly for '.' or '..'... I don't think it even does that. All it does is resolve the root inode of the filesystem. The code path for mounting a UFS or UFS2 filesystem is very short. -Matt From owner-freebsd-fs@FreeBSD.ORG Tue Feb 19 03:41:49 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C03216A418 for ; Tue, 19 Feb 2008 03:41:49 +0000 (UTC) (envelope-from Lowell@Be-Well.Ilk.Org) Received: from be-well.ilk.org (dsl092-078-145.bos1.dsl.speakeasy.net [66.92.78.145]) by mx1.freebsd.org (Postfix) with ESMTP id 6433613C442 for ; Tue, 19 Feb 2008 03:41:49 +0000 (UTC) (envelope-from Lowell@Be-Well.Ilk.Org) Received: from Lowell-Desk.lan (Lowell-Desk.lan [172.30.250.6]) by be-well.ilk.org (Postfix) with ESMTP id 71EB528472; Mon, 18 Feb 2008 22:26:43 -0500 (EST) Received: by Lowell-Desk.lan (Postfix, from userid 1147) id 5BD721CC72; Mon, 18 Feb 2008 22:26:42 -0500 (EST) To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= References: <47B90868.7000900@electron-tube.net> <86odae5rgr.fsf@ds4.des.no> From: Lowell Gilbert Date: Mon, 18 Feb 2008 22:26:42 -0500 Message-ID: <44k5l1mxsd.fsf@Lowell-Desk.lan> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 03:41:49 -0000 Dag-Erling Sm=F8rgrav writes: > Jim Bryant writes: >> #include >> #include >> >> int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, 1024= ); for(i =3D 0; i < 10000; i++) { sprintf(buf, "touch %s%05d\n", argv[1], i= ); system((const char *)buf);} return(0);} > > Subject should be "how to take down a system [...] with three lines of > badly written C, provided you have root privileges already and are too > lazy to just dd if=3D/dev/zero of=3D/dev/ad0s1 count=3D100", which would > accomplish the job much faster. I don't really see that argument, given that I can't understand *why* this code would produce the specific symptoms described in the original message.=20=20 For the record, I've been unable to reproduce the problem, so I'm unwilling to get too excited about it. > Purely in the interest of showing off, here is my version. It is 81 > bytes shorter than yours, it is valid C99 with POSIX extensions (yours > is not), and it produces 11,450 files in about 0.2% of the time yours > takes to produce 10,000. > > #include > #define b(i,v) for(int v=3D48;v<127;++v){f[i]=3Dv; > #define a(i) b(i,v##i) > int main(void){char f[5]=3D{'/'};a(1)a(2)a(3)truncate(f,0);}}}} Entertaining, but not enough so to win the Obfuscated C contest.=20=20 I'm a pretty dedicated C user, but on this subject I've been using shell scripts for testing. From owner-freebsd-fs@FreeBSD.ORG Tue Feb 19 18:02:17 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 846C816A468 for ; Tue, 19 Feb 2008 18:02:17 +0000 (UTC) (envelope-from admin@su29.net) Received: from aliska.alo.ru (aliska.alo.ru [80.251.131.12]) by mx1.freebsd.org (Postfix) with ESMTP id 3643F13C4D9 for ; Tue, 19 Feb 2008 18:02:16 +0000 (UTC) (envelope-from admin@su29.net) Received: from aliska (aliska.alo.ru [80.251.131.12]) by aliska.alo.ru (Postfix) with SMTP id 1E18A24CB55 for ; Tue, 19 Feb 2008 21:02:15 +0300 (MSK) Received: from ws.su29.net (ppp85-141-154-230.pppoe.mtu-net.ru [85.141.154.230]) by aliska.alo.ru (Postfix) with ESMTP id B968224CA77 for ; Tue, 19 Feb 2008 21:02:14 +0300 (MSK) Message-ID: <47BB1995.9010102@su29.net> Date: Tue, 19 Feb 2008 21:01:57 +0300 From: "Alexander V. Chernikov" Organization: AlmazTelecom User-Agent: Thunderbird 2.0.0.9 (X11/20080210) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: kern/117829: [unionfs] can't mount devfs on top of unionfs anymore X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: admin@su29.net List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 18:02:17 -0000 Can anybody take a look at this PR? Problem seems to be not directly unionfs related. From owner-freebsd-fs@FreeBSD.ORG Wed Feb 20 07:37:10 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F66016A400; Wed, 20 Feb 2008 07:37:10 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id E5B3A13C46A; Wed, 20 Feb 2008 07:36:36 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (unknown [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTP id B122028454; Wed, 20 Feb 2008 15:36:22 +0800 (CST) Received: from localhost (unknown [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id 75ECCEC4224; Wed, 20 Feb 2008 15:36:22 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id PKZE85EwkG3v; Wed, 20 Feb 2008 15:36:16 +0800 (CST) Received: from charlie.delphij.net (c-67-161-39-180.hsd1.ca.comcast.net [67.161.39.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id CE533EB662B; Wed, 20 Feb 2008 15:36:07 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:openpgp:content-type; b=Z/aTHOBQkGOHWQgplsjRDtCaxct9R3V1OtctCUcfl4D+cLnaLDylw6HY/Q42IXCtU 97d5wULXFfxJIhTJIJ7xg== Message-ID: <47BBD864.3070905@delphij.net> Date: Tue, 19 Feb 2008 23:36:04 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20080122) MIME-Version: 1.0 To: freebsd-fs@freebsd.org, FreeBSD Current X-Enigmail-Version: 0.95.5 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------080801040108060000080409" Cc: Subject: [PATCH FOR REVIEW] fsck_ffs: Recover from catastrophic damage X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 07:37:10 -0000 This is a multi-part message in MIME format. --------------080801040108060000080409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Here is a patch that will help fsck_ffs(8) to recover from certain types of damages which is caused by some catastrophic damage seen in some disk arrays that does not detect data errors in time. Change summary: fsutil.c: - Really update standard superblock. fsck_ffs -b used to update the backup superblock which does not recover file systems which have bad master superblocks. - Instead of coredump, zero out whole cg if its signature is bad. inode.c: - Instead of coredump, zero out whole cg if its signature is bad. pass1.c: - If cg gives insane initediblk, use a fallback one which will not cause allocation failure. setup.c: - Really sanity check the superblock's fs_sbsize. With these changes, fsck_ffs will be able to check file systems with heavily damaged cylinder group information, and have a better chance surviving. Comments? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHu9hji+vbBBjt66ARAqSyAJ49q4uEIANxr4/ccaVKeLTDomiFVQCfVB0i kLZsrSPTifwvItwC3WMq40E= =vvkQ -----END PGP SIGNATURE----- --------------080801040108060000080409 Content-Type: text/plain; name="fsck.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fsck.diff" Index: fsutil.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/fsutil.c,v retrieving revision 1.26 diff -u -p -r1.26 fsutil.c --- fsutil.c 31 Oct 2006 22:06:56 -0000 1.26 +++ fsutil.c 20 Feb 2008 07:15:56 -0000 @@ -301,7 +301,7 @@ ckfini(int markclean) if (havesb && cursnapshot == 0 && sblock.fs_magic == FS_UFS2_MAGIC && sblk.b_bno != sblock.fs_sblockloc / dev_bsize && !preen && reply("UPDATE STANDARD SUPERBLOCK")) { - sblk.b_bno = sblock.fs_sblockloc / dev_bsize; + sblk.b_bno = SBLOCK_UFS2 / dev_bsize; sbdirty(); flush(fswritefd, &sblk); } @@ -441,8 +441,13 @@ allocblk(long frags) } cg = dtog(&sblock, i + j); getblk(&cgblk, cgtod(&sblock, cg), sblock.fs_cgsize); - if (!cg_chkmagic(cgp)) - pfatal("CG %d: BAD MAGIC NUMBER\n", cg); + if (!cg_chkmagic(cgp)) { + pwarn("CG %d: BAD MAGIC NUMBER\n", cg); + memset(cgp, 0, (size_t)sblock.fs_cgsize); + cgp->cg_niblk = sblock.fs_ipg; + cgp->cg_ndblk = sblock.fs_size - cgbase(&sblock, cg); + cgp->cg_magic = CG_MAGIC; + } baseblk = dtogd(&sblock, i + j); for (k = 0; k < frags; k++) { setbmap(i + j + k); Index: inode.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/inode.c,v retrieving revision 1.38 diff -u -p -r1.38 inode.c --- inode.c 31 Oct 2006 22:06:56 -0000 1.38 +++ inode.c 20 Feb 2008 07:15:22 -0000 @@ -617,8 +617,13 @@ allocino(ino_t request, int type) return (0); cg = ino_to_cg(&sblock, ino); getblk(&cgblk, cgtod(&sblock, cg), sblock.fs_cgsize); - if (!cg_chkmagic(cgp)) - pfatal("CG %d: BAD MAGIC NUMBER\n", cg); + if (!cg_chkmagic(cgp)) { + pwarn("CG %d: BAD MAGIC NUMBER\n", cg); + memset(cgp, 0, (size_t)sblock.fs_cgsize); + cgp->cg_niblk = sblock.fs_ipg; + cgp->cg_ndblk = sblock.fs_size - cgbase(&sblock, cg); + cgp->cg_magic = CG_MAGIC; + } setbit(cg_inosused(cgp), ino % sblock.fs_ipg); cgp->cg_cs.cs_nifree--; switch (type & IFMT) { Index: pass1.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/pass1.c,v retrieving revision 1.43 diff -u -p -r1.43 pass1.c --- pass1.c 8 Oct 2004 20:44:47 -0000 1.43 +++ pass1.c 20 Feb 2008 07:13:53 -0000 @@ -93,9 +93,11 @@ pass1(void) inumber = c * sblock.fs_ipg; setinodebuf(inumber); getblk(&cgblk, cgtod(&sblock, c), sblock.fs_cgsize); - if (sblock.fs_magic == FS_UFS2_MAGIC) + if (sblock.fs_magic == FS_UFS2_MAGIC) { inosused = cgrp.cg_initediblk; - else + if (inosused > sblock.fs_ipg) + inosused = sblock.fs_ipg; + } else inosused = sblock.fs_ipg; if (got_siginfo) { printf("%s: phase 1: cyl group %d of %d (%d%%)\n", Index: setup.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/setup.c,v retrieving revision 1.50 diff -u -p -r1.50 setup.c --- setup.c 31 Oct 2006 22:06:56 -0000 1.50 +++ setup.c 20 Feb 2008 07:13:27 -0000 @@ -349,7 +349,7 @@ readsb(int listerr) sblock.fs_sblockloc == sblock_try[i])) && sblock.fs_ncg >= 1 && sblock.fs_bsize >= MINBSIZE && - sblock.fs_bsize >= sizeof(struct fs)) + sblock.fs_sbsize >= roundup(sizeof(struct fs), dev_bsize)) break; } if (sblock_try[i] == -1) { --------------080801040108060000080409-- From owner-freebsd-fs@FreeBSD.ORG Wed Feb 20 07:42:09 2008 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EB6516A402; Wed, 20 Feb 2008 07:42:09 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EDA1E13C442; Wed, 20 Feb 2008 07:42:08 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1K7g8Yt084163; Wed, 20 Feb 2008 07:42:08 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1K7g8dn084159; Wed, 20 Feb 2008 07:42:08 GMT (envelope-from remko) Date: Wed, 20 Feb 2008 07:42:08 GMT Message-Id: <200802200742.m1K7g8dn084159@freefall.freebsd.org> To: remko@FreeBSD.org, imp@FreeBSD.org, freebsd-fs@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 07:42:09 -0000 Synopsis: [procfs] 'stat' shows that all files have 0-length when they are actually not empty Responsible-Changed-From-To: imp->freebsd-fs Responsible-Changed-By: remko Responsible-Changed-When: Wed Feb 20 07:42:08 UTC 2008 Responsible-Changed-Why: OK Warner wasn't the right person to redirect to, forward over to the FS group http://www.freebsd.org/cgi/query-pr.cgi?pr=120869 From owner-freebsd-fs@FreeBSD.ORG Wed Feb 20 08:10:47 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B195216A404 for ; Wed, 20 Feb 2008 08:10:47 +0000 (UTC) (envelope-from rink@tragedy.rink.nu) Received: from mx1.rink.nu (alastor.rink.nu [213.34.49.5]) by mx1.freebsd.org (Postfix) with ESMTP id 7115A13C447 for ; Wed, 20 Feb 2008 08:10:47 +0000 (UTC) (envelope-from rink@tragedy.rink.nu) Received: from localhost (alastor.rink.nu [213.34.49.5]) by mx1.rink.nu (Postfix) with ESMTP id 47D7EBFEC9E; Wed, 20 Feb 2008 07:53:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.5]) by localhost (alastor.rink.nu [213.34.49.5]) (amavisd-new, port 10024) with ESMTP id MyLZCGM1uWng; Wed, 20 Feb 2008 07:52:58 +0000 (UTC) Received: from tragedy.rink.nu (tragedy.rink.nu [213.34.49.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.rink.nu (Postfix) with ESMTP id 7976CBFE830; Wed, 20 Feb 2008 07:52:58 +0000 (UTC) Received: from tragedy.rink.nu (tragedy.rink.nu [213.34.49.3]) by tragedy.rink.nu (8.13.8/8.13.8) with ESMTP id m1K7qwSb058492; Wed, 20 Feb 2008 08:52:58 +0100 (CET) (envelope-from rink@tragedy.rink.nu) Received: (from rink@localhost) by tragedy.rink.nu (8.13.8/8.13.8/Submit) id m1K7qvvB058489; Wed, 20 Feb 2008 08:52:57 +0100 (CET) (envelope-from rink) Date: Wed, 20 Feb 2008 08:52:57 +0100 From: Rink Springer To: d@delphij.net Message-ID: <20080220075257.GE43512@rink.nu> References: <47BBD864.3070905@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47BBD864.3070905@delphij.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-fs@freebsd.org, FreeBSD Current Subject: Re: [PATCH FOR REVIEW] fsck_ffs: Recover from catastrophic damage X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 08:10:47 -0000 Hi Xin, On Tue, Feb 19, 2008 at 11:36:04PM -0800, Xin LI wrote: > Comments? This looks fine to me - I don't see anything obviously wrong in there. -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From owner-freebsd-fs@FreeBSD.ORG Wed Feb 20 09:56:29 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 818DD16A400; Wed, 20 Feb 2008 09:56:29 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 3C22613C457; Wed, 20 Feb 2008 09:56:29 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55516.dip.t-dialin.net [84.165.85.22]) by redbull.bpaserver.net (Postfix) with ESMTP id 6024C2E068; Wed, 20 Feb 2008 10:56:17 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 5371693C31; Wed, 20 Feb 2008 10:56:15 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.2/8.13.8/Submit) id m1K9uECI010729; Wed, 20 Feb 2008 10:56:14 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Wed, 20 Feb 2008 10:56:14 +0100 Message-ID: <20080220105614.eydtkfap4gogk0cw@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 20 Feb 2008 10:56:14 +0100 From: Alexander Leidinger To: d@delphij.net, Xin LI References: <47BBD864.3070905@delphij.net> In-Reply-To: <47BBD864.3070905@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.5) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 6, BAYES_00 -15.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-fs@freebsd.org, FreeBSD Current Subject: Re: [PATCH FOR REVIEW] fsck_ffs: Recover from catastrophic damage X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 09:56:29 -0000 Quoting Xin LI (from Tue, 19 Feb 2008 23:36:04 -0800): > Change summary: > > fsutil.c: > - Really update standard superblock. fsck_ffs -b used to update the > backup superblock which does not recover file systems which have bad > master superblocks. > - Instead of coredump, zero out whole cg if its signature is bad. > > inode.c: > - Instead of coredump, zero out whole cg if its signature is bad. Does this modify (zero out) on-disk blocks? If yes, shouldn't this ask for confirmation? Bye, Alexander. -- I've been there. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-fs@FreeBSD.ORG Wed Feb 20 09:58:52 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 612D516A403; Wed, 20 Feb 2008 09:58:52 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 349A413C45B; Wed, 20 Feb 2008 09:58:49 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (unknown [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTP id 41DA32844D; Wed, 20 Feb 2008 17:58:48 +0800 (CST) Received: from localhost (unknown [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id 0D253EC42E5; Wed, 20 Feb 2008 17:58:48 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id JDI7nKmHAiIP; Wed, 20 Feb 2008 17:58:43 +0800 (CST) Received: from charlie.delphij.net (c-67-161-39-180.hsd1.ca.comcast.net [67.161.39.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 55B9CEB0B5A; Wed, 20 Feb 2008 17:58:39 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=hd0if4plfnipRsEqHEt3uSD1l2qoI0K8ALfwIavRtc3CmaeySeO30Uapp+2zmDKh8 VK82Ls8x8t2TRT6EorDHg== Message-ID: <47BBF9CC.4030404@delphij.net> Date: Wed, 20 Feb 2008 01:58:36 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20080122) MIME-Version: 1.0 To: Alexander Leidinger References: <47BBD864.3070905@delphij.net> <20080220105614.eydtkfap4gogk0cw@webmail.leidinger.net> In-Reply-To: <20080220105614.eydtkfap4gogk0cw@webmail.leidinger.net> X-Enigmail-Version: 0.95.5 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, FreeBSD Current , d@delphij.net Subject: Re: [PATCH FOR REVIEW] fsck_ffs: Recover from catastrophic damage X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 09:58:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexander Leidinger wrote: > Quoting Xin LI (from Tue, 19 Feb 2008 23:36:04 > -0800): > >> Change summary: >> >> fsutil.c: >> - Really update standard superblock. fsck_ffs -b used to update the >> backup superblock which does not recover file systems which have bad >> master superblocks. >> - Instead of coredump, zero out whole cg if its signature is bad. >> >> inode.c: >> - Instead of coredump, zero out whole cg if its signature is bad. > > Does this modify (zero out) on-disk blocks? If yes, shouldn't this ask > for confirmation? My assumption is that if a cylinder group's magic number is damaged, then the whole stuff can not be trusted at all, but yes, I think this should come with a prompt, will add tomorrow. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHu/nMi+vbBBjt66ARAqN9AJ4zRi6+h0f6R062vQyuEkET32saEACguKSs 4GxuVJdwFt7bIuKlGouO5Dk= =fMnQ -----END PGP SIGNATURE----- From owner-freebsd-fs@FreeBSD.ORG Wed Feb 20 12:08:22 2008 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A74C716A40A; Wed, 20 Feb 2008 12:08:22 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 68A1113C474; Wed, 20 Feb 2008 12:08:22 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1KC8MWn009292; Wed, 20 Feb 2008 12:08:22 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1KC8MHi009288; Wed, 20 Feb 2008 12:08:22 GMT (envelope-from remko) Date: Wed, 20 Feb 2008 12:08:22 GMT Message-Id: <200802201208.m1KC8MHi009288@freefall.freebsd.org> To: yuri@tsoft.com, remko@FreeBSD.org, freebsd-fs@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 12:08:22 -0000 Synopsis: [procfs] 'stat' shows that all files have 0-length when they are actually not empty State-Changed-From-To: open->closed State-Changed-By: remko State-Changed-When: Wed Feb 20 12:08:22 UTC 2008 State-Changed-Why: After a bit of discussion, this is not something which we are going to fix. It is not worth the hassle. If you think this should be different, we do welcome patches. Thanks fo rusing FreeBSD! http://www.freebsd.org/cgi/query-pr.cgi?pr=120869 From owner-freebsd-fs@FreeBSD.ORG Wed Feb 20 13:32:31 2008 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A23716A400; Wed, 20 Feb 2008 13:32:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id B7B2913C442; Wed, 20 Feb 2008 13:32:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 4FF6446BCA; Wed, 20 Feb 2008 08:32:30 -0500 (EST) Date: Wed, 20 Feb 2008 13:32:30 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: remko@FreeBSD.org In-Reply-To: <200802201208.m1KC8MHi009288@freefall.freebsd.org> Message-ID: <20080220132030.S14519@fledge.watson.org> References: <200802201208.m1KC8MHi009288@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org, yuri@tsoft.com, bug-followup@FreeBSD.org Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 13:32:31 -0000 On Wed, 20 Feb 2008, remko@FreeBSD.org wrote: > After a bit of discussion, this is not something which we are going to fix. > It is not worth the hassle. If you think this should be different, we do > welcome patches. Thanks fo rusing FreeBSD! Just as two data points here: Solaris attempts to provide coherent file sizes in /proc (at least to the extent that tried a few for objects where it is remotely possible), and the Linux 2.6.12 kernel I have on a box locally basically doesn't. My view is that it's a synthetic file system with data that varies dynamically at runtime, and that while it wouldn't hurt to produce file size information that's correct, it's quite a bit of work to do so and that I wouldn't prioritize it above other, more critical things that need to happen. We should certainly evaluate any patches that come in for possible inclusion, assuming they don't muck up the internals of procfs too much; it's not clear to me if they necessarily do so or not. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Wed Feb 20 13:40:03 2008 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3F5316A402 for ; Wed, 20 Feb 2008 13:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DDBAC13C4DD for ; Wed, 20 Feb 2008 13:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1KDe28W021988 for ; Wed, 20 Feb 2008 13:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1KDe298021987; Wed, 20 Feb 2008 13:40:02 GMT (envelope-from gnats) Date: Wed, 20 Feb 2008 13:40:02 GMT Message-Id: <200802201340.m1KDe298021987@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Robert Watson Cc: Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Robert Watson List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 13:40:03 -0000 The following reply was made to PR kern/120869; it has been noted by GNATS. From: Robert Watson To: remko@FreeBSD.org Cc: yuri@tsoft.com, freebsd-fs@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty Date: Wed, 20 Feb 2008 13:32:30 +0000 (GMT) On Wed, 20 Feb 2008, remko@FreeBSD.org wrote: > After a bit of discussion, this is not something which we are going to fix. > It is not worth the hassle. If you think this should be different, we do > welcome patches. Thanks fo rusing FreeBSD! Just as two data points here: Solaris attempts to provide coherent file sizes in /proc (at least to the extent that tried a few for objects where it is remotely possible), and the Linux 2.6.12 kernel I have on a box locally basically doesn't. My view is that it's a synthetic file system with data that varies dynamically at runtime, and that while it wouldn't hurt to produce file size information that's correct, it's quite a bit of work to do so and that I wouldn't prioritize it above other, more critical things that need to happen. We should certainly evaluate any patches that come in for possible inclusion, assuming they don't muck up the internals of procfs too much; it's not clear to me if they necessarily do so or not. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Wed Feb 20 16:53:59 2008 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B391B16A400; Wed, 20 Feb 2008 16:53:59 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 5F7C013C458; Wed, 20 Feb 2008 16:53:59 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 2EFA72088; Wed, 20 Feb 2008 17:53:53 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 16111207F; Wed, 20 Feb 2008 17:53:53 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id EE34484488; Wed, 20 Feb 2008 17:53:52 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Robert Watson References: <200802201208.m1KC8MHi009288@freefall.freebsd.org> <20080220132030.S14519@fledge.watson.org> Date: Wed, 20 Feb 2008 17:53:52 +0100 In-Reply-To: <20080220132030.S14519@fledge.watson.org> (Robert Watson's message of "Wed\, 20 Feb 2008 13\:32\:30 +0000 \(GMT\)") Message-ID: <86ve4jvaan.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@FreeBSD.org, remko@FreeBSD.org, yuri@tsoft.com, bug-followup@FreeBSD.org Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 16:53:59 -0000 Robert Watson writes: > Just as two data points here: Solaris attempts to provide coherent > file sizes in /proc (at least to the extent that tried a few for > objects where it is remotely possible), and the Linux 2.6.12 kernel I > have on a box locally basically doesn't. Correct; neither to more recent Linux kernels. 2.6.12 is ancient! :) > My view is that it's a synthetic file system with data that varies > dynamically at runtime, and that while it wouldn't hurt to produce > file size information that's correct, it's quite a bit of work to do > so and that I wouldn't prioritize it above other, more critical things > that need to happen. Most of the time, it can't be done. Some of the files in /proc have a fixed size (/proc/$$/{,db,fp}regs for instance), but others have highly variable content, and there is no other way to figure out how large it is than to generate it. Even then, it may change between the stat(2) call and the read(2) call. A good example is /proc/$$/status, which among other things contains a textual representation of the process's user and system time in seconds and microseconds. A process reading its own /proc/$$/status will get inconsistent results. As for /proc/$$/map, the simple act of malloc()ing a buffer for it may change its contents if jemalloc needs to mmap() a new chunk. Some files actually *don't* have any size, such as /proc/$$/ctl, which is write-only. > We should certainly evaluate any patches that come in for possible > inclusion, assuming they don't muck up the internals of procfs too > much; it's not clear to me if they necessarily do so or not. I'll be glad to review and commit patches, but procfs doesn't have any internals to speak of, all it does is provide content for pseudofs. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Wed Feb 20 17:10:02 2008 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEBF616A405 for ; Wed, 20 Feb 2008 17:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B45E913C4CC for ; Wed, 20 Feb 2008 17:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1KHA2gW038054 for ; Wed, 20 Feb 2008 17:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1KHA2gR038053; Wed, 20 Feb 2008 17:10:02 GMT (envelope-from gnats) Date: Wed, 20 Feb 2008 17:10:02 GMT Message-Id: <200802201710.m1KHA2gR038053@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Cc: Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 17:10:02 -0000 The following reply was made to PR kern/120869; it has been noted by GNATS. From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Robert Watson Cc: remko@FreeBSD.org, freebsd-fs@FreeBSD.org, yuri@tsoft.com, bug-followup@FreeBSD.org Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty Date: Wed, 20 Feb 2008 17:53:52 +0100 Robert Watson writes: > Just as two data points here: Solaris attempts to provide coherent > file sizes in /proc (at least to the extent that tried a few for > objects where it is remotely possible), and the Linux 2.6.12 kernel I > have on a box locally basically doesn't. Correct; neither to more recent Linux kernels. 2.6.12 is ancient! :) > My view is that it's a synthetic file system with data that varies > dynamically at runtime, and that while it wouldn't hurt to produce > file size information that's correct, it's quite a bit of work to do > so and that I wouldn't prioritize it above other, more critical things > that need to happen. Most of the time, it can't be done. Some of the files in /proc have a fixed size (/proc/$$/{,db,fp}regs for instance), but others have highly variable content, and there is no other way to figure out how large it is than to generate it. Even then, it may change between the stat(2) call and the read(2) call. A good example is /proc/$$/status, which among other things contains a textual representation of the process's user and system time in seconds and microseconds. A process reading its own /proc/$$/status will get inconsistent results. As for /proc/$$/map, the simple act of malloc()ing a buffer for it may change its contents if jemalloc needs to mmap() a new chunk. Some files actually *don't* have any size, such as /proc/$$/ctl, which is write-only. > We should certainly evaluate any patches that come in for possible > inclusion, assuming they don't muck up the internals of procfs too > much; it's not clear to me if they necessarily do so or not. I'll be glad to review and commit patches, but procfs doesn't have any internals to speak of, all it does is provide content for pseudofs. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Wed Feb 20 21:01:20 2008 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8014E16A401; Wed, 20 Feb 2008 21:01:20 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 3B55413C469; Wed, 20 Feb 2008 21:01:20 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.3] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m1KKXkiI054531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 12:33:50 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <47BC8E3E.2090706@FreeBSD.org> Date: Wed, 20 Feb 2008 12:31:58 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: d@delphij.net References: <47BBD864.3070905@delphij.net> <20080220105614.eydtkfap4gogk0cw@webmail.leidinger.net> <47BBF9CC.4030404@delphij.net> In-Reply-To: <47BBF9CC.4030404@delphij.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, Alexander Leidinger , FreeBSD Current Subject: Re: [PATCH FOR REVIEW] fsck_ffs: Recover from catastrophic damage X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 21:01:20 -0000 Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Alexander Leidinger wrote: >> Quoting Xin LI (from Tue, 19 Feb 2008 23:36:04 >> -0800): >> >>> Change summary: >>> >>> fsutil.c: >>> - Really update standard superblock. fsck_ffs -b used to update the >>> backup superblock which does not recover file systems which have bad >>> master superblocks. >>> - Instead of coredump, zero out whole cg if its signature is bad. >>> >>> inode.c: >>> - Instead of coredump, zero out whole cg if its signature is bad. >> Does this modify (zero out) on-disk blocks? If yes, shouldn't this ask >> for confirmation? > > My assumption is that if a cylinder group's magic number is damaged, > then the whole stuff can not be trusted at all, but yes, I think this > should come with a prompt, will add tomorrow. Does it make sense to make this functionality only available if some special command-line flag has been specified? For example in the presence of silent data corruption (which as we all know now is real) it is possible that read would return incorrect data, while it's still perfectly OK on disk. Zeroing data would make an irreversible damage in such case. IMHO, fsck should bail by default in such case, since it can't tell for sure what the source of the error is. -Maxim From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 07:57:21 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2707D16A400 for ; Thu, 21 Feb 2008 07:57:21 +0000 (UTC) (envelope-from antik@bsd.ee) Received: from zzz.ee (kalah.zzz.ee [194.204.30.253]) by mx1.freebsd.org (Postfix) with ESMTP id CF7D713C4EB for ; Thu, 21 Feb 2008 07:57:19 +0000 (UTC) (envelope-from antik@bsd.ee) Received: by zzz.ee (Postfix, from userid 3019) id CDE66828EFA; Thu, 21 Feb 2008 09:58:03 +0200 (EET) X-Spam-Checker-Version: SpamAssassin on spamassassin.zzz.ee X-Spam-Level: X-Spam-Guessed-Language: en X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,BAYES_50 X-Spam-Checker-URL: http://info.zzz.ee Received: from andrei.demo (adsl215.uninet.ee [194.204.62.215]) by zzz.ee (Postfix) with ESMTP id 6E0078289F3 for ; Thu, 21 Feb 2008 09:58:02 +0200 (EET) From: Andrei Kolu To: freebsd-fs@freebsd.org Date: Thu, 21 Feb 2008 09:57:13 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802210957.13651.antik@bsd.ee> Subject: FreeBSD 6.3 ACL problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 07:57:21 -0000 Hi, I have this strange problem with ACL- I can go to one particular directory with two different users but can't access it with third. NOTE: there is no common group set up like samba- all users access this directory according to ACL rules (other::r-x). Looks like different shell does not matter (csh or sh). Only difference whas that I created user "antik" before I enabled ACL support for /usr filesystem. Should I report this like bug? Commands listing: --------------------------------------------------------------------- sambatest# pwd /root sambatest# cd /home/ sambatest# ll total 10 drwxr-xr-x 2 antik antik 512 Feb 20 16:23 antik drwxrwxr-x+ 3 samba samba 512 Feb 20 15:53 samba drwxr-xr-x 2 test1 test1 512 Feb 21 09:29 test1 drwxr-xr-x 2 test2 test2 512 Feb 20 16:40 test2 sambatest# getfacl samba/ #file:samba/ #owner:1003 #group:1003 user::rwx user:nobody:rw- group::r-x group:wheel:rw- mask::rwx other::r-x sambatest# su - antik %cd /home/ %ll total 10 drwxr-xr-x 2 antik antik 512 Feb 20 16:23 antik drwxrwxr-x+ 3 samba samba 512 Feb 20 15:53 samba drwxr-xr-x 2 test1 test1 512 Feb 21 09:29 test1 drwxr-xr-x 2 test2 test2 512 Feb 20 16:40 test2 %cd samba/ samba/: Permission denied. %logout sambatest# su - test2 $ cd /home $ ll total 14 drwxr-xr-x 6 root wheel - 512 Feb 20 16:40 ./ drwxr-xr-x 17 root wheel - 512 Feb 20 14:01 ../ drwxr-xr-x 2 antik antik - 512 Feb 20 16:23 antik/ drwxrwxr-x+ 3 samba samba - 512 Feb 20 15:53 samba/ drwxr-xr-x 2 test1 test1 - 512 Feb 21 09:29 test1/ drwxr-xr-x 2 test2 test2 - 512 Feb 20 16:40 test2/ $ cd samba $ pwd /home/samba --------------------------------------------------------------------- From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 08:21:57 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D73916A400 for ; Thu, 21 Feb 2008 08:21:57 +0000 (UTC) (envelope-from antik@bsd.ee) Received: from zzz.ee (kalah.zzz.ee [194.204.30.253]) by mx1.freebsd.org (Postfix) with ESMTP id 0818113C469 for ; Thu, 21 Feb 2008 08:21:55 +0000 (UTC) (envelope-from antik@bsd.ee) Received: by zzz.ee (Postfix, from userid 3019) id 6A950828B74; Thu, 21 Feb 2008 10:22:38 +0200 (EET) X-Spam-Checker-Version: SpamAssassin on spamassassin.zzz.ee X-Spam-Level: X-Spam-Guessed-Language: en X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,BAYES_50 X-Spam-Checker-URL: http://info.zzz.ee Received: from andrei.demo (adsl215.uninet.ee [194.204.62.215]) by zzz.ee (Postfix) with ESMTP id D79238288CA for ; Thu, 21 Feb 2008 10:22:29 +0200 (EET) From: Andrei Kolu To: freebsd-fs@freebsd.org Date: Thu, 21 Feb 2008 10:21:40 +0200 User-Agent: KMail/1.9.7 References: <200802210957.13651.antik@bsd.ee> <20080221081511.GA12457@harmless.hu> In-Reply-To: <20080221081511.GA12457@harmless.hu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802211021.41060.antik@bsd.ee> Subject: Re: FreeBSD 6.3 ACL problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 08:21:57 -0000 On Thursday 21 February 2008 10:15:11 Gergely CZUCZY wrote: > run ``id antik'' please. I've got a feeling that your antik user is > part of the "wheel" group, which is not allowed to chdir into that > directory. > sambatest# id antik uid=1001(antik) gid=1001(antik) groups=1001(antik),0(wheel) I should remove this user from wheel group or add particular permission? So wheel does not fit onto "other" definition in ACL? > On Thu, Feb 21, 2008 at 09:57:13AM +0200, Andrei Kolu wrote: > > Hi, I have this strange problem with ACL- I can go to one particular > > directory with two different users but can't access it with third. NOTE: > > there is no common group set up like samba- all users access this > > directory according to ACL rules (other::r-x). Looks like different shell > > does not matter (csh or sh). Only difference whas that I created user > > "antik" before I enabled ACL support for /usr filesystem. Should I report > > this like bug? > > > > Commands listing: > > --------------------------------------------------------------------- > > sambatest# pwd > > /root > > sambatest# cd /home/ > > sambatest# ll > > total 10 > > drwxr-xr-x 2 antik antik 512 Feb 20 16:23 antik > > drwxrwxr-x+ 3 samba samba 512 Feb 20 15:53 samba > > drwxr-xr-x 2 test1 test1 512 Feb 21 09:29 test1 > > drwxr-xr-x 2 test2 test2 512 Feb 20 16:40 test2 > > sambatest# getfacl samba/ > > #file:samba/ > > #owner:1003 > > #group:1003 > > user::rwx > > user:nobody:rw- > > group::r-x > > group:wheel:rw- > > mask::rwx > > other::r-x > > sambatest# su - antik > > %cd /home/ > > %ll > > total 10 > > drwxr-xr-x 2 antik antik 512 Feb 20 16:23 antik > > drwxrwxr-x+ 3 samba samba 512 Feb 20 15:53 samba > > drwxr-xr-x 2 test1 test1 512 Feb 21 09:29 test1 > > drwxr-xr-x 2 test2 test2 512 Feb 20 16:40 test2 > > %cd samba/ > > samba/: Permission denied. > > %logout > > sambatest# su - test2 > > $ cd /home > > $ ll > > total 14 > > drwxr-xr-x 6 root wheel - 512 Feb 20 16:40 ./ > > drwxr-xr-x 17 root wheel - 512 Feb 20 14:01 ../ > > drwxr-xr-x 2 antik antik - 512 Feb 20 16:23 antik/ > > drwxrwxr-x+ 3 samba samba - 512 Feb 20 15:53 samba/ > > drwxr-xr-x 2 test1 test1 - 512 Feb 21 09:29 test1/ > > drwxr-xr-x 2 test2 test2 - 512 Feb 20 16:40 test2/ > > $ cd samba > > $ pwd > > /home/samba > > --------------------------------------------------------------------- > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > Sincerely, > > Gergely Czuczy, > Harmless Digital > mailto: gergely.czuczy@harmless.hu From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 08:43:32 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEBF316A404 for ; Thu, 21 Feb 2008 08:43:32 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id 175AC13C4EC for ; Thu, 21 Feb 2008 08:43:32 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id 7A9307BFE5E; Thu, 21 Feb 2008 09:24:06 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.5.3 (20071212) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id sq6f8vlfXyZH; Thu, 21 Feb 2008 09:24:06 +0100 (CET) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id 852AD7BFE79; Thu, 21 Feb 2008 09:24:05 +0100 (CET) Date: Thu, 21 Feb 2008 09:24:05 +0100 From: Gergely CZUCZY To: Andrei Kolu Message-ID: <20080221082405.GA13505@harmless.hu> References: <200802210957.13651.antik@bsd.ee> <20080221081511.GA12457@harmless.hu> <200802211021.41060.antik@bsd.ee> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <200802211021.41060.antik@bsd.ee> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-fs@freebsd.org Subject: Re: FreeBSD 6.3 ACL problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 08:43:32 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 21, 2008 at 10:21:40AM +0200, Andrei Kolu wrote: > On Thursday 21 February 2008 10:15:11 Gergely CZUCZY wrote: > > run ``id antik'' please. I've got a feeling that your antik user is > > part of the "wheel" group, which is not allowed to chdir into that > > directory. > > > sambatest# id antik > uid=3D1001(antik) gid=3D1001(antik) groups=3D1001(antik),0(wheel) >=20 > I should remove this user from wheel group or add particular permission? = So=20 > wheel does not fit onto "other" definition in ACL?=20 It perfectly fits into that. Just that, the definition for wheel comes firs= t, since that's more specific. More specific first, general ones later, if i remembe= r correctly. I suggest fixiing the ACLs, that seems to be a solution. OTOH, removing him= from wheel seems to be a workaround. >=20 > > On Thu, Feb 21, 2008 at 09:57:13AM +0200, Andrei Kolu wrote: > > > Hi, I have this strange problem with ACL- I can go to one particular > > > directory with two different users but can't access it with third. NO= TE: > > > there is no common group set up like samba- all users access this > > > directory according to ACL rules (other::r-x). Looks like different s= hell > > > does not matter (csh or sh). Only difference whas that I created user > > > "antik" before I enabled ACL support for /usr filesystem. Should I re= port > > > this like bug? > > > > > > Commands listing: > > > --------------------------------------------------------------------- > > > sambatest# pwd > > > /root > > > sambatest# cd /home/ > > > sambatest# ll > > > total 10 > > > drwxr-xr-x 2 antik antik 512 Feb 20 16:23 antik > > > drwxrwxr-x+ 3 samba samba 512 Feb 20 15:53 samba > > > drwxr-xr-x 2 test1 test1 512 Feb 21 09:29 test1 > > > drwxr-xr-x 2 test2 test2 512 Feb 20 16:40 test2 > > > sambatest# getfacl samba/ > > > #file:samba/ > > > #owner:1003 > > > #group:1003 > > > user::rwx > > > user:nobody:rw- > > > group::r-x > > > group:wheel:rw- > > > mask::rwx > > > other::r-x > > > sambatest# su - antik > > > %cd /home/ > > > %ll > > > total 10 > > > drwxr-xr-x 2 antik antik 512 Feb 20 16:23 antik > > > drwxrwxr-x+ 3 samba samba 512 Feb 20 15:53 samba > > > drwxr-xr-x 2 test1 test1 512 Feb 21 09:29 test1 > > > drwxr-xr-x 2 test2 test2 512 Feb 20 16:40 test2 > > > %cd samba/ > > > samba/: Permission denied. > > > %logout > > > sambatest# su - test2 > > > $ cd /home > > > $ ll > > > total 14 > > > drwxr-xr-x 6 root wheel - 512 Feb 20 16:40 ./ > > > drwxr-xr-x 17 root wheel - 512 Feb 20 14:01 ../ > > > drwxr-xr-x 2 antik antik - 512 Feb 20 16:23 antik/ > > > drwxrwxr-x+ 3 samba samba - 512 Feb 20 15:53 samba/ > > > drwxr-xr-x 2 test1 test1 - 512 Feb 21 09:29 test1/ > > > drwxr-xr-x 2 test2 test2 - 512 Feb 20 16:40 test2/ > > > $ cd samba > > > $ pwd > > > /home/samba > > > --------------------------------------------------------------------- > > > _______________________________________________ > > > freebsd-fs@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > > > Sincerely, > > > > Gergely Czuczy, > > Harmless Digital > > mailto: gergely.czuczy@harmless.hu >=20 >=20 > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" Sincerely, Gergely Czuczy, Harmless Digital mailto: gergely.czuczy@harmless.hu --=20 Legacy software is software that works. --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) owHlV0+P20QUX1pxsQRtjxxAT2mr3Wpjx0423daQblfb0i60LNDlQDm0jj22R2t7 wsy42fQTcOgBcUECgbhyQAKJaxGfgAsIiRPiA/AdeDNjJ84mW1rUG/tHdt6835v3 fu/PTD596eTKiTO/fP/jR+uPPvvyhe9e/mG4npdSFomdB/wBLWzPdT3b6/Xdvr2B T3I52nDjzSi8FPc2oxuP++d2WCFJIe39yYj4IMmh7IyygBavQ5gGXBA5KGVsX7Jq vWtUjJigkrLCB1pktCDTtX0eFCIm3L5ehCyiReLDxyWTJLJHnBYyGGbEsvYK2E/L NrxJhtD12tB13UsQSPBcv+v5G+72bVh3UdiG7SLihMLbLCthzNGOb10BA+ciCiYI V1Z4GfCJMYM2vL7veXCD8IRkE9i5+8HO3Q9n6CvAywLu36cRBIWkB6urMMpIIIgD u6sPCCRMQgAxIRhXAjJFvyas5EYZSkE4UKHtjAIugcWoQ6A1ThHRgoSzctSGcUrD FPWgUNayjI1JBJIhoRFFfIGvyrI2gxISSsYnjvqI/yLIh4EkQp6F2kmUljQa9K6p ZK5p0QVIFiVqdzEvbLtr2rcL1pVB10VDuyBSVmYRcJIzDFim6KeOK+YsB61sLAHD sKNIB0rDMgs4jAjPqRCY+i0YWHeYMWkwESMm4JgiLyrGFkNueAsiEtNCFwzGDts7 t7YUblcqczEGj2lCjJgR48BbpZD6ta35bViI0SuzYchy3DGmXAws1BO0CImlMKsC csYJiBEJaUxDB243P2oIAhJSEB5k6CuayZBy3gYaA1XMkHxIBhbHPTjXHjqWhcyV SYKJQQOH1JQHUeGItikUQUguVJ6HBGtIYNUqjx3Y29+72TZ8K1RK84Gl2bZMIPO4 MeMHAfJfRLhnlbS66hebxr3s9zd9r/cvTaN+b9I2Zj8N6qQLid2aEBhxhn2Jqacy VeHYqBUGBbaC8gnZaVRAZWpatAYkxwxFMTY+DgFdTAKGpVRWVrEBwpAIzK6slFPK Iwfe2RtY+9dr31ShENMxKq85JtrUIM4fwEdGD4jpDFs1VLVHZVlFs+AYrjEe6Swx FRX2fYZ5XtM16fvcPrzgwC3GDoQxPvMfyyklWVZbrMs6DySWCKyFIlWdIVLE7xVY uzUyJFiYgTC1gBRygjUVaVcrWy3dky3Mc6wKchdIoUZipP0T5WjEcKSoAu+UAvuR osMTIUnuwB3Ts7tYRQNLqU15o5X/wzLZMsJqaQdpDIpILQupRnElt5/HT2WrMatG 46gSdjhjclEhjKCTYst2FpemZEsmsSE9t+aejw8xUfgH0K1GcP3oe13TDC54F/1u bzopp0CNXYee2QnqRxPY9/vV8tIdlXce1I8p0FNd171s5McCu1A/5l3dcI18kYaE yDgIMyOqaTqrysCfF7ExTi4fp3yvluhmaUpU1WGVjw+bnws2ZNEEpXX+DEw1w5xA j6WGWh6Ig6axWQ8tBiFKsOdycf5o4s//n9Ot2JhLpvngw7vToxVPu4KSyJnSxRJW LmkozXTT9rlpj00FR6neWOI/XATVsfhijiO0uhCC01kC9DafCNzwXQ+cpciF9B7d sk5wZ0mGF1JsH5PkY3aeT7N9TKKfAJ6leglTeqXTzEiz4M4156Ruiubq8xzN957t p0LFnJChiOxYXK1eHcYTHABU34fVUVJpplKO/E5HSYTT0O0oXTx4OubYiVlnZrOC 7jMoC1EORcjpkODNjRTqojvR26jjujWD2A3Npkstqz7p7qh7H8e7fnsqml7+H5bh QyOHmwHPM3VbuEYTir1gmcFGM8l8nLwa4IQacDWtdJ20rG5g5hr27Jw+HZ//kcvn w6PVINA6ytwCa0/BmGXbiq5bJAnCCV6DYzkOzOVu+q6vSOqiKxzrk62TL66oL6L1 t9gzJ048Wvm691t2+Ld76vHPr77/2g3/lXt/xMP+yleny5b3+Ren17/51v7rvd// PLX96xs//QM= =XAEw -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 08:43:33 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF7EE16A400 for ; Thu, 21 Feb 2008 08:43:33 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id 08C6113C4F6 for ; Thu, 21 Feb 2008 08:43:32 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id 9FA937BFE69; Thu, 21 Feb 2008 09:15:13 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.5.3 (20071212) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id T5fwoxOG-s14; Thu, 21 Feb 2008 09:15:13 +0100 (CET) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id 758A17BFE75; Thu, 21 Feb 2008 09:15:11 +0100 (CET) Date: Thu, 21 Feb 2008 09:15:11 +0100 From: Gergely CZUCZY To: Andrei Kolu Message-ID: <20080221081511.GA12457@harmless.hu> References: <200802210957.13651.antik@bsd.ee> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <200802210957.13651.antik@bsd.ee> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-fs@freebsd.org Subject: Re: FreeBSD 6.3 ACL problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 08:43:33 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable run ``id antik'' please. I've got a feeling that your antik user is part of the "wheel" group, which is not allowed to chdir into that directory. On Thu, Feb 21, 2008 at 09:57:13AM +0200, Andrei Kolu wrote: > Hi, I have this strange problem with ACL- I can go to one particular dire= ctory=20 > with two different users but can't access it with third. NOTE: there is n= o=20 > common group set up like samba- all users access this directory according= to=20 > ACL rules (other::r-x). Looks like different shell does not matter (csh o= r=20 > sh). Only difference whas that I created user "antik" before I enabled AC= L=20 > support for /usr filesystem. Should I report this like bug? >=20 > Commands listing: > --------------------------------------------------------------------- > sambatest# pwd > /root > sambatest# cd /home/ > sambatest# ll > total 10 > drwxr-xr-x 2 antik antik 512 Feb 20 16:23 antik > drwxrwxr-x+ 3 samba samba 512 Feb 20 15:53 samba > drwxr-xr-x 2 test1 test1 512 Feb 21 09:29 test1 > drwxr-xr-x 2 test2 test2 512 Feb 20 16:40 test2 > sambatest# getfacl samba/ > #file:samba/ > #owner:1003 > #group:1003 > user::rwx > user:nobody:rw- > group::r-x > group:wheel:rw- > mask::rwx > other::r-x > sambatest# su - antik > %cd /home/ > %ll > total 10 > drwxr-xr-x 2 antik antik 512 Feb 20 16:23 antik > drwxrwxr-x+ 3 samba samba 512 Feb 20 15:53 samba > drwxr-xr-x 2 test1 test1 512 Feb 21 09:29 test1 > drwxr-xr-x 2 test2 test2 512 Feb 20 16:40 test2 > %cd samba/ > samba/: Permission denied. > %logout > sambatest# su - test2 > $ cd /home > $ ll > total 14 > drwxr-xr-x 6 root wheel - 512 Feb 20 16:40 ./ > drwxr-xr-x 17 root wheel - 512 Feb 20 14:01 ../ > drwxr-xr-x 2 antik antik - 512 Feb 20 16:23 antik/ > drwxrwxr-x+ 3 samba samba - 512 Feb 20 15:53 samba/ > drwxr-xr-x 2 test1 test1 - 512 Feb 21 09:29 test1/ > drwxr-xr-x 2 test2 test2 - 512 Feb 20 16:40 test2/ > $ cd samba > $ pwd > /home/samba > --------------------------------------------------------------------- > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >=20 Sincerely, Gergely Czuczy, Harmless Digital mailto: gergely.czuczy@harmless.hu --=20 Legacy software is software that works. --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) owHlVs1v3EQUD60QwuJD5S942rZKIGt7vR9N4mrbRmlpIlJS1Nwq0c7aY3sUe8ad GcfZHjkhVAmEhITEodwQEiAOHIErnLhwgf+AC2cOXHhjr/cjH0hIvbFayTNv3vvN e7/f84w/evn80rkLv3z73f3VJx9/9tzXL/41eiMrtOaxnRF5yLjtdTqe7XX7gzW7 b/c2vH6P9Eg4oOtr6xu3f+i9siW4plzb++Oc+qDpkXbzlDB+FYKESEX1sNCRvW41 fjeZyoVimgnuA+Mp43S6ti8JVxGV9i0eiJDx2IdHhdA0tHPJuCajlFqWLDg8fMhC IFyzg+VlyFNKFHVgZ/mQQiw0EIgoReAYdEI0jEUha2coFJXAlJUTqUFEuE6hVSbo 3YJYiiJvQ5mwIEEf4AYpTUVJQ9ACqwkZxnIcGlQLZzTQQo4dy9rjsJ8UbXiTjqDr taHb6awD7tzZ8AdrvtfbvAOrHTS2YZOHkjJ4S6QFlBJL861rsM3asAMJwfR1gjsr jTzEFHIpsOIMSqYT2NzatdErIBxrNAkJjh5YBwuKlEgw+QytKqNht4OoVZQuBa5E yCnyW5WvYFRoA7OM5QUBVQqYnjgnTIYOvL23f8s31Eha8TC0RI0YiCwTvCYKUFnA R8oOKCiSjYht2JpsMQGuqpkSZaxCGlmHFhZQY2JZIIuUKlgRZkvfl/bR6w7sCnGg avRZ/iqhuEUoaK1ORrRGPVcClYAYWrJGVAmG7/F0PA0MKKpKVN0NSKGkBHuqboZW 1RgtGNFIYL07QLlpsxATG1q7E8QizwU2DHqAWygJEcOEx0rTzIF7iSjSEAMlrZyq mqu8R0V83bpWQ2whdYSHZkVp09hos5/Fz6Rn2NdU6YuQlyEaXCmEXlwIQnATkVF3 0ZymONdCkxQ8k2YoyyPkH/8A3ck70zwGXrdu8A54V/xur7Y3QVXcKvRqdGge80ED fzBZPrGTycaD5jEN8swb1N2o7acGdaF5LKbX79T2xXJjqiMSpLXJUHHRKOnPpqLk 2IJ45PXMrGr0Zma6BZuzPGrGXIxEOEaL0aB2Nb07nVTHymQ5I+qgCZ61+WJyqgB7 yunlecEu/x9kMhVPhagHPtylMmNK4V0BIeWMhk5Fh4hFoU9hr8G6NO33ajJPX/9Y fnAFzNuCg0ovQJQTKTrusSBv7V+D+n7HA+dE1Ampjm/ViOUeU+uEXPYZgp2y46Jk 9hminRE4k+0UVqoVt2G7aZhLzRlUNW9jfVZH3YP/9sOISFI6UqEdqRuToSNkjC8k qz4QzHGMXonWue+6ZqacOT/X+OHB7dbHdiTcGR6G7QsouCpGKpBsRNt4J3LzWTKu 4M0d3Zq523Oe86m06ivCusfwnpI0Hbct6zaVMY5g63ERPEbDNpFZai7Umyxm2MaW wdfCxwOtcnSCyvFGMvFzksKybNvg7tKYBGNQItIlqS/06bi6D0shD5RjvX/9/PNL 5nuu+Ra8cO7+C0tP77zz8593X/o0e+1ou/v73184v/36o7/0+SfvfvNTr/f0ve9l 8NUfTz748HDl1S//AQ== =Jn66 -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 09:24:21 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BD8116A408; Thu, 21 Feb 2008 09:24:21 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.freebsd.org (Postfix) with ESMTP id C866013C455; Thu, 21 Feb 2008 09:24:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1L9ODLw016663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 20:24:15 +1100 Date: Thu, 21 Feb 2008 20:24:13 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Robert Watson In-Reply-To: <20080220132030.S14519@fledge.watson.org> Message-ID: <20080221202027.B29307@delplex.bde.org> References: <200802201208.m1KC8MHi009288@freefall.freebsd.org> <20080220132030.S14519@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, yuri@tsoft.com, bug-followup@freebsd.org Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 09:24:21 -0000 On Wed, 20 Feb 2008, Robert Watson wrote: > On Wed, 20 Feb 2008, remko@FreeBSD.org wrote: > >> After a bit of discussion, this is not something which we are going to fix. >> It is not worth the hassle. If you think this should be different, we do >> welcome patches. Thanks fo rusing FreeBSD! > > Just as two data points here: Solaris attempts to provide coherent file sizes > in /proc (at least to the extent that tried a few for objects where it is > remotely possible), and the Linux 2.6.12 kernel I have on a box locally > basically doesn't. > > My view is that it's a synthetic file system with data that varies > dynamically at runtime, and that while it wouldn't hurt to produce file size > information that's correct, it's quite a bit of work to do so and that I > wouldn't prioritize it above other, more critical things that need to happen. > We should certainly evaluate any patches that come in for possible inclusion, > assuming they don't muck up the internals of procfs too much; it's not clear > to me if they necessarily do so or not. The bug is mainly that stat() claims that the files are regular when they highly irregular (they are more like fifos). This confuses naive applications into thinking that normal access methods for regular files actually work. Bruce From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 09:36:05 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68B2A16A407; Thu, 21 Feb 2008 09:36:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 433BD13C45B; Thu, 21 Feb 2008 09:36:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C533A46B93; Thu, 21 Feb 2008 04:36:04 -0500 (EST) Date: Thu, 21 Feb 2008 09:36:04 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Bruce Evans In-Reply-To: <20080221202027.B29307@delplex.bde.org> Message-ID: <20080221093203.Y52922@fledge.watson.org> References: <200802201208.m1KC8MHi009288@freefall.freebsd.org> <20080220132030.S14519@fledge.watson.org> <20080221202027.B29307@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, yuri@tsoft.com, bug-followup@freebsd.org Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 09:36:05 -0000 On Thu, 21 Feb 2008, Bruce Evans wrote: > On Wed, 20 Feb 2008, Robert Watson wrote: > >> On Wed, 20 Feb 2008, remko@FreeBSD.org wrote: >> >>> After a bit of discussion, this is not something which we are going to >>> fix. It is not worth the hassle. If you think this should be different, we >>> do welcome patches. Thanks fo rusing FreeBSD! >> >> Just as two data points here: Solaris attempts to provide coherent file >> sizes in /proc (at least to the extent that tried a few for objects where >> it is remotely possible), and the Linux 2.6.12 kernel I have on a box >> locally basically doesn't. >> >> My view is that it's a synthetic file system with data that varies >> dynamically at runtime, and that while it wouldn't hurt to produce file >> size information that's correct, it's quite a bit of work to do so and that >> I wouldn't prioritize it above other, more critical things that need to >> happen. We should certainly evaluate any patches that come in for possible >> inclusion, assuming they don't muck up the internals of procfs too much; >> it's not clear to me if they necessarily do so or not. > > The bug is mainly that stat() claims that the files are regular when they > highly irregular (they are more like fifos). This confuses naive > applications into thinking that normal access methods for regular files > actually work. I feel this way more generally about synthetic file systems with objects in them that don't correspond with any of the standard file system objects that applications known how to deal with. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 09:40:03 2008 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49FE716A401 for ; Thu, 21 Feb 2008 09:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4002013C465 for ; Thu, 21 Feb 2008 09:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1L9e3sr027524 for ; Thu, 21 Feb 2008 09:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1L9e3Gl027523; Thu, 21 Feb 2008 09:40:03 GMT (envelope-from gnats) Date: Thu, 21 Feb 2008 09:40:03 GMT Message-Id: <200802210940.m1L9e3Gl027523@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Robert Watson Cc: Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Robert Watson List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 09:40:03 -0000 The following reply was made to PR kern/120869; it has been noted by GNATS. From: Robert Watson To: Bruce Evans Cc: remko@freebsd.org, freebsd-fs@freebsd.org, yuri@tsoft.com, bug-followup@freebsd.org Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty Date: Thu, 21 Feb 2008 09:36:04 +0000 (GMT) On Thu, 21 Feb 2008, Bruce Evans wrote: > On Wed, 20 Feb 2008, Robert Watson wrote: > >> On Wed, 20 Feb 2008, remko@FreeBSD.org wrote: >> >>> After a bit of discussion, this is not something which we are going to >>> fix. It is not worth the hassle. If you think this should be different, we >>> do welcome patches. Thanks fo rusing FreeBSD! >> >> Just as two data points here: Solaris attempts to provide coherent file >> sizes in /proc (at least to the extent that tried a few for objects where >> it is remotely possible), and the Linux 2.6.12 kernel I have on a box >> locally basically doesn't. >> >> My view is that it's a synthetic file system with data that varies >> dynamically at runtime, and that while it wouldn't hurt to produce file >> size information that's correct, it's quite a bit of work to do so and that >> I wouldn't prioritize it above other, more critical things that need to >> happen. We should certainly evaluate any patches that come in for possible >> inclusion, assuming they don't muck up the internals of procfs too much; >> it's not clear to me if they necessarily do so or not. > > The bug is mainly that stat() claims that the files are regular when they > highly irregular (they are more like fifos). This confuses naive > applications into thinking that normal access methods for regular files > actually work. I feel this way more generally about synthetic file systems with objects in them that don't correspond with any of the standard file system objects that applications known how to deal with. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 10:11:52 2008 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C21E016A400; Thu, 21 Feb 2008 10:11:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 4986713C455; Thu, 21 Feb 2008 10:11:51 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1LABkMH013966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 21:11:48 +1100 Date: Thu, 21 Feb 2008 21:11:46 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Robert Watson In-Reply-To: <20080221093203.Y52922@fledge.watson.org> Message-ID: <20080221210145.C4879@besplex.bde.org> References: <200802201208.m1KC8MHi009288@freefall.freebsd.org> <20080220132030.S14519@fledge.watson.org> <20080221202027.B29307@delplex.bde.org> <20080221093203.Y52922@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org, remko@FreeBSD.org, yuri@tsoft.com, bug-followup@FreeBSD.org Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 10:11:52 -0000 On Thu, 21 Feb 2008, Robert Watson wrote: > On Thu, 21 Feb 2008, Bruce Evans wrote: >>> [about files in procfs] >> The bug is mainly that stat() claims that the files are regular when they >> highly irregular (they are more like fifos). This confuses naive >> applications into thinking that normal access methods for regular files >> actually work. > > I feel this way more generally about synthetic file systems with objects in > them that don't correspond with any of the standard file system objects that > applications known how to deal with. Enough to break compatibility/portabiility by adding a new file type? :-) S_IFMT has 4 bits, so it could encode 16 file types, but it currently only encodes 8. It looks like it once had only 3 bits but was expanded for fifos. It was last changed in ~1993 in 4.4BSD to add whiteouts. Bruce From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 10:20:05 2008 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BAA716A402 for ; Thu, 21 Feb 2008 10:20:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1172213C455 for ; Thu, 21 Feb 2008 10:20:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1LAK46r031066 for ; Thu, 21 Feb 2008 10:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1LAK4iW031065; Thu, 21 Feb 2008 10:20:04 GMT (envelope-from gnats) Date: Thu, 21 Feb 2008 10:20:04 GMT Message-Id: <200802211020.m1LAK4iW031065@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Bruce Evans Cc: Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 10:20:05 -0000 The following reply was made to PR kern/120869; it has been noted by GNATS. From: Bruce Evans To: Robert Watson Cc: Bruce Evans , remko@FreeBSD.org, freebsd-fs@FreeBSD.org, yuri@tsoft.com, bug-followup@FreeBSD.org Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty Date: Thu, 21 Feb 2008 21:11:46 +1100 (EST) On Thu, 21 Feb 2008, Robert Watson wrote: > On Thu, 21 Feb 2008, Bruce Evans wrote: >>> [about files in procfs] >> The bug is mainly that stat() claims that the files are regular when they >> highly irregular (they are more like fifos). This confuses naive >> applications into thinking that normal access methods for regular files >> actually work. > > I feel this way more generally about synthetic file systems with objects in > them that don't correspond with any of the standard file system objects that > applications known how to deal with. Enough to break compatibility/portabiility by adding a new file type? :-) S_IFMT has 4 bits, so it could encode 16 file types, but it currently only encodes 8. It looks like it once had only 3 bits but was expanded for fifos. It was last changed in ~1993 in 4.4BSD to add whiteouts. Bruce From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 11:34:14 2008 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75A2B16A403; Thu, 21 Feb 2008 11:34:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3975613C459; Thu, 21 Feb 2008 11:34:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 3B27246BF8; Thu, 21 Feb 2008 06:34:13 -0500 (EST) Date: Thu, 21 Feb 2008 11:34:13 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Bruce Evans In-Reply-To: <20080221210145.C4879@besplex.bde.org> Message-ID: <20080221112718.X64109@fledge.watson.org> References: <200802201208.m1KC8MHi009288@freefall.freebsd.org> <20080220132030.S14519@fledge.watson.org> <20080221202027.B29307@delplex.bde.org> <20080221093203.Y52922@fledge.watson.org> <20080221210145.C4879@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org, remko@FreeBSD.org, yuri@tsoft.com, bug-followup@FreeBSD.org Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 11:34:14 -0000 On Thu, 21 Feb 2008, Bruce Evans wrote: > On Thu, 21 Feb 2008, Robert Watson wrote: > >> On Thu, 21 Feb 2008, Bruce Evans wrote: >>>> [about files in procfs] >>> The bug is mainly that stat() claims that the files are regular when they >>> highly irregular (they are more like fifos). This confuses naive >>> applications into thinking that normal access methods for regular files >>> actually work. >> >> I feel this way more generally about synthetic file systems with objects in >> them that don't correspond with any of the standard file system objects >> that applications known how to deal with. > > Enough to break compatibility/portabiility by adding a new file type? :-) > S_IFMT has 4 bits, so it could encode 16 file types, but it currently only > encodes 8. It looks like it once had only 3 bits but was expanded for > fifos. It was last changed in ~1993 in 4.4BSD to add whiteouts. Not that much :-). If someone hadn't been working to fix unionfs recently, I'd suggest GCing the whiteout flag so that we did, in fact, have a spare bit. That said, work to reduce dependence on procfs seems to be gradually getting done. There are a few things left, such as ps -e and gcore that could use some attention. Once nice thing about /proc/$pid/mem is that you can use it asynchronously with respect to the process and in a way that is non-interfering with its debugging and signal delivery. We almost want a ptrace attachment mode that specifies in advance that no execution flow interference will occur, just allowing memory access, register snapshots, etc, rather than an attachment necessarily getting in the signal delivery path (etc). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 11:40:03 2008 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B84EB16A408 for ; Thu, 21 Feb 2008 11:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id ACEB213C447 for ; Thu, 21 Feb 2008 11:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1LBe3Cu039700 for ; Thu, 21 Feb 2008 11:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1LBe3Nw039699; Thu, 21 Feb 2008 11:40:03 GMT (envelope-from gnats) Date: Thu, 21 Feb 2008 11:40:03 GMT Message-Id: <200802211140.m1LBe3Nw039699@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Robert Watson Cc: Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Robert Watson List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 11:40:03 -0000 The following reply was made to PR kern/120869; it has been noted by GNATS. From: Robert Watson To: Bruce Evans Cc: remko@FreeBSD.org, freebsd-fs@FreeBSD.org, yuri@tsoft.com, bug-followup@FreeBSD.org Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty Date: Thu, 21 Feb 2008 11:34:13 +0000 (GMT) On Thu, 21 Feb 2008, Bruce Evans wrote: > On Thu, 21 Feb 2008, Robert Watson wrote: > >> On Thu, 21 Feb 2008, Bruce Evans wrote: >>>> [about files in procfs] >>> The bug is mainly that stat() claims that the files are regular when they >>> highly irregular (they are more like fifos). This confuses naive >>> applications into thinking that normal access methods for regular files >>> actually work. >> >> I feel this way more generally about synthetic file systems with objects in >> them that don't correspond with any of the standard file system objects >> that applications known how to deal with. > > Enough to break compatibility/portabiility by adding a new file type? :-) > S_IFMT has 4 bits, so it could encode 16 file types, but it currently only > encodes 8. It looks like it once had only 3 bits but was expanded for > fifos. It was last changed in ~1993 in 4.4BSD to add whiteouts. Not that much :-). If someone hadn't been working to fix unionfs recently, I'd suggest GCing the whiteout flag so that we did, in fact, have a spare bit. That said, work to reduce dependence on procfs seems to be gradually getting done. There are a few things left, such as ps -e and gcore that could use some attention. Once nice thing about /proc/$pid/mem is that you can use it asynchronously with respect to the process and in a way that is non-interfering with its debugging and signal delivery. We almost want a ptrace attachment mode that specifies in advance that no execution flow interference will occur, just allowing memory access, register snapshots, etc, rather than an attachment necessarily getting in the signal delivery path (etc). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 11:41:49 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDE9716A400 for ; Thu, 21 Feb 2008 11:41:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from anti-4.kiev.sovam.com (anti-4.kiev.sovam.com [62.64.120.202]) by mx1.freebsd.org (Postfix) with ESMTP id 7564213C45B for ; Thu, 21 Feb 2008 11:41:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by anti-4.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JS8Sr-000BSx-Ow; Thu, 21 Feb 2008 12:15:44 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id m1KBEMAO079394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 13:14:22 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m1KBEifa026674; Wed, 20 Feb 2008 13:14:44 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m1KBEiTH026673; Wed, 20 Feb 2008 13:14:44 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Feb 2008 13:14:44 +0200 From: Kostik Belousov To: d@delphij.net Message-ID: <20080220111444.GH57756@deviant.kiev.zoral.com.ua> References: <47BBD864.3070905@delphij.net> <20080220105614.eydtkfap4gogk0cw@webmail.leidinger.net> <47BBF9CC.4030404@delphij.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CzROh2enfuzgPXpq" Content-Disposition: inline In-Reply-To: <47BBF9CC.4030404@delphij.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 1118cf21f7425d415ed61e91afc5cb63 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2271 [Feb 20 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: freebsd-fs@freebsd.org, Alexander Leidinger , FreeBSD Current Subject: Re: [PATCH FOR REVIEW] fsck_ffs: Recover from catastrophic damage X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 11:41:49 -0000 --CzROh2enfuzgPXpq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2008 at 01:58:36AM -0800, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Alexander Leidinger wrote: > > Quoting Xin LI (from Tue, 19 Feb 2008 23:36:04 > > -0800): > >=20 > >> Change summary: > >> > >> fsutil.c: > >> - Really update standard superblock. fsck_ffs -b used to update the > >> backup superblock which does not recover file systems which have bad > >> master superblocks. > >> - Instead of coredump, zero out whole cg if its signature is bad. > >> > >> inode.c: > >> - Instead of coredump, zero out whole cg if its signature is bad. > >=20 > > Does this modify (zero out) on-disk blocks? If yes, shouldn't this ask > > for confirmation? >=20 > My assumption is that if a cylinder group's magic number is damaged, > then the whole stuff can not be trusted at all, but yes, I think this > should come with a prompt, will add tomorrow. I have some uneasy feeling about automatically zeroing a cg. I think it would be safer to show the message there, and add the same functionality to fsdb, something like clrcg command, analogous to clri. --CzROh2enfuzgPXpq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAke8C6MACgkQC3+MBN1Mb4hvnACeLqs9DokpnnsjAcFSWXrxLYDq 1iIAnjNMukCTe1AzihTKlCP1jAi+zLvG =ltem -----END PGP SIGNATURE----- --CzROh2enfuzgPXpq-- From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 12:32:08 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A6DB16A404; Thu, 21 Feb 2008 12:32:08 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 1137F13C468; Thu, 21 Feb 2008 12:32:08 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id B5F9643CC85; Thu, 21 Feb 2008 14:32:06 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNNHte2ZE-y4; Thu, 21 Feb 2008 14:32:06 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 4905E43CAD5; Thu, 21 Feb 2008 14:32:06 +0200 (EET) Message-ID: <47BD6F39.7080105@icyb.net.ua> Date: Thu, 21 Feb 2008 14:31:53 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: freebsd-geom@freebsd.org, freebsd-fs@freebsd.org, freebsd-current@freebsd.org References: <47B81D07.7090208@icyb.net.ua> In-Reply-To: <47B81D07.7090208@icyb.net.ua> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: newfs_msdos and dvd-ram (fwsectors, fwheads) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 12:32:08 -0000 on 17/02/2008 13:39 Andriy Gapon said the following: > Should newfs_msdos be able to work on "whole" cdX/acdX device ? > [ufs/ffs] newfs can do it. > But with newfs_msdos I had to run disklabel first and then I could > create a filesystem on cdXa, but I couldn't do it on the whole disk. It seems that the reason for this newfs_msdos behavior is in the following lines: if (ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1) errx(1, "Cannot get sector size, %s", strerror(errno)); if (ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1) errx(1, "Cannot get number of sectors, %s", strerror(errno)); if (ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks)== -1) errx(1, "Cannot get number of heads, %s", strerror(errno)); While a failure to get sector size is a serious situation indeed, number of sectors per track and number of heads are just relics of the past and are not applicable to all types of should-be-supported media. What's even more funny is that those values can be set via command line options and in that case values from ioctl are not used at all. Because those numbers are used by msdosfs on-disk structures we have to provide some reasonable values for them even if they are meaningless with respect to physical media organization. An example of simple calculations can be found in bsdlabel.c. I see two approaches: 1) fake those properties in device drivers, primarily cd(4) and acd(4); benefit: this can help other utilities besides newfs_msdos 2) fake those properties in newfs_msdof; benefit: this would help with other physical devices that can host FAT; Or maybe do both. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 14:10:03 2008 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFD8A16A403 for ; Thu, 21 Feb 2008 14:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B0CCA13C448 for ; Thu, 21 Feb 2008 14:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1LEA355054115 for ; Thu, 21 Feb 2008 14:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1LEA3VL054112; Thu, 21 Feb 2008 14:10:03 GMT (envelope-from gnats) Date: Thu, 21 Feb 2008 14:10:03 GMT Message-Id: <200802211410.m1LEA3VL054112@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Bruce Evans Cc: Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 14:10:03 -0000 The following reply was made to PR kern/120869; it has been noted by GNATS. From: Bruce Evans To: Robert Watson Cc: remko@freebsd.org, freebsd-fs@freebsd.org, yuri@tsoft.com, bug-followup@freebsd.org Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty Date: Thu, 21 Feb 2008 20:24:13 +1100 (EST) On Wed, 20 Feb 2008, Robert Watson wrote: > On Wed, 20 Feb 2008, remko@FreeBSD.org wrote: > >> After a bit of discussion, this is not something which we are going to fix. >> It is not worth the hassle. If you think this should be different, we do >> welcome patches. Thanks fo rusing FreeBSD! > > Just as two data points here: Solaris attempts to provide coherent file sizes > in /proc (at least to the extent that tried a few for objects where it is > remotely possible), and the Linux 2.6.12 kernel I have on a box locally > basically doesn't. > > My view is that it's a synthetic file system with data that varies > dynamically at runtime, and that while it wouldn't hurt to produce file size > information that's correct, it's quite a bit of work to do so and that I > wouldn't prioritize it above other, more critical things that need to happen. > We should certainly evaluate any patches that come in for possible inclusion, > assuming they don't muck up the internals of procfs too much; it's not clear > to me if they necessarily do so or not. The bug is mainly that stat() claims that the files are regular when they highly irregular (they are more like fifos). This confuses naive applications into thinking that normal access methods for regular files actually work. Bruce From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 14:27:34 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAAD316A402 for ; Thu, 21 Feb 2008 14:27:34 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id EC6A313C455 for ; Thu, 21 Feb 2008 14:27:28 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1LERONJ022421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 01:27:25 +1100 Date: Fri, 22 Feb 2008 01:27:24 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andriy Gapon In-Reply-To: <47BD6F39.7080105@icyb.net.ua> Message-ID: <20080222005213.W5655@besplex.bde.org> References: <47B81D07.7090208@icyb.net.ua> <47BD6F39.7080105@icyb.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: newfs_msdos and dvd-ram (fwsectors, fwheads) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 14:27:35 -0000 On Thu, 21 Feb 2008, Andriy Gapon wrote: > on 17/02/2008 13:39 Andriy Gapon said the following: >> Should newfs_msdos be able to work on "whole" cdX/acdX device ? >> [ufs/ffs] newfs can do it. >> But with newfs_msdos I had to run disklabel first and then I could >> create a filesystem on cdXa, but I couldn't do it on the whole disk. > > It seems that the reason for this newfs_msdos behavior is in the > following lines: > if (ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1) > errx(1, "Cannot get sector size, %s", strerror(errno)); > if (ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1) > errx(1, "Cannot get number of sectors, %s", strerror(errno)); > if (ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks)== -1) > errx(1, "Cannot get number of heads, %s", strerror(errno)); > > While a failure to get sector size is a serious situation indeed, number > of sectors per track and number of heads are just relics of the past and > are not applicable to all types of should-be-supported media. > What's even more funny is that those values can be set via command line > options and in that case values from ioctl are not used at all. Also, it needs the BIOS geometry, but has been broken to ask for, and normally use, the firmware geometry. Setting the values on the command line is a fairly easy workaround. It's actually better for the ioctls and make you give the correct parameters on the command line instead of succeeding and giving wrong values. The "hidden sectors" calculation has also been broken. This can be fixed by setting the value on the command line too. The correct setting is normally or always the offset of the partition in sectors. > Because those numbers are used by msdosfs on-disk structures we have to > provide some reasonable values for them even if they are meaningless > with respect to physical media organization. > An example of simple calculations can be found in bsdlabel.c. Those don't give the BIOS geometry, which isn't a problem in disklabel since disklabel doesn't need any geometry, but newfs_msdos, fsck_msdosfs fdisk and sysinstall need more. newfs_msdos, fdisk and sysinstall used to read values from the label (including the label for the whole disk), and these parameters used to be set to the kernel's best guess at the BIOS geometry, so that everything saw a consistent geometry. fsck_msdosfs has never missed not being able to determine the correct values, since it has never checked or fixed the values. WinXP silently fixes at least "hidden sectors" at boot time. > I see two approaches: > 1) fake those properties in device drivers, primarily cd(4) and acd(4); > benefit: this can help other utilities besides newfs_msdos > 2) fake those properties in newfs_msdof; > benefit: this would help with other physical devices that can host > FAT; > > Or maybe do both. This won't help for other utilities that need the BIOS geometry. I use the following fixes in newfs_msdos. They reduce mainly to complaints about the breakage and trying alternative ioctls so that the same binary has some chance of working on new and old versions of FreeBSD. I didn't restore the DIOCGSLICEINFO ioctl or the code that uses it to determine "hidden sectors". Another possible fix for this is to use the NetBSD version, which last time I looked was just the FreeBSD version with all the unportable ioctls and code ifdefed out. The 2004/09/24 version of it reduces to assuming that the correct (BIOS) values are in the label. It attempts to calculate "hidden sectors" where FreeBSD now sets it to 0. I think this works iff the offsets in the label are absolute. FreeBSD used to virtualize these offsets to well to be 0-based, and I think these offsets can be physically 0-based now. It is necessary to know the base, which my unimplemented DICOMEDIAOFFSET ioctl returns. % Index: newfs_msdos.c % =================================================================== % RCS file: /home/ncvs/src/sbin/newfs_msdos/newfs_msdos.c,v % retrieving revision 1.20 % diff -u -2 -r1.20 newfs_msdos.c % --- newfs_msdos.c 17 Feb 2004 02:02:18 -0000 1.20 % +++ newfs_msdos.c 22 Apr 2004 10:36:28 -0000 % @@ -711,56 +711,165 @@ % struct bpb *bpb) % { % - struct disklabel *lp, dlp; % - struct fd_type type; % - off_t ms, hs; % - % - lp = NULL; % - % - /* If the user specified a disk type, try to use that */ % + struct fd_type fdtype; % + struct disklabel label, *lp; % + off_t ms, mo; % + u_int heads, secpertrack, secsize; % + u_int cruftmap, fwheads, fwsectors; % + % +#define NO_MEDIASIZE (1 << 0) % +#define NO_MEDIAOFFSET (1 << 1) % +#define NO_SECTORSIZE (1 << 2) % +#define NO_HEADS (1 << 3) % +#define NO_SECPERTRACK (1 << 4) % +#define NO_FWHEADS (1 << 5) % +#define NO_FWSECTORS (1 << 6) % +#define NO_FDTYPE (1 << 7) % +#define NO_LABEL (1 << 8) % + cruftmap = 0; % + % + /* First, try to use only the "right" primitive ioctls. */ % + if (ioctl(fd, DIOCGMEDIASIZE, &ms) == -1) % + cruftmap |= NO_MEDIASIZE; % +#ifdef DIOCGMEDIAOFFSET % + if (ioctl(fd, DIOCGMEDIAOFFSET, &mo) == -1) % +#endif % + cruftmap |= NO_MEDIAOFFSET; % + if (ioctl(fd, DIOCGSECTORSIZE, &secsize) == -1) % + cruftmap |= NO_SECTORSIZE; % +#ifdef DIOCGHEADS % + if (ioctl(fd, DIOCGHEADS, &nheads)== -1) % +#endif % + cruftmap |= NO_HEADS; % +#ifdef DIOCGSECPERTRACK % + if (ioctl(fd, DIOCGSECPERTRACK, &secpertrack) == -1) % +#endif % + cruftmap |= NO_SECPERTRACK; % + % + /* Prepare fallbacks. */ % + if (ioctl(fd, DIOCGFWHEADS, &fwheads) == -1) % + cruftmap |= NO_FWHEADS; % + if (ioctl(fd, DIOCGFWSECTORS, &fwsectors) == -1) % + cruftmap |= NO_FWSECTORS; % + if (ioctl(fd, FD_GTYPE, &fdtype) == -1) % + cruftmap |= NO_FDTYPE; % if (dtype != NULL) { % lp = getdiskbyname(dtype); % - hs = 0; % + if (lp == NULL) % + errx(1, "%s: unknown disk type", dtype); % + label = *lp; % + } else if (ioctl(fd, DIOCGDINFO, &label) == -1) % + cruftmap |= NO_LABEL; % + % + /* % + * Preliminary fallback for firmware heads and sectors: use floppy ones. % + * Non-GEOM drivers don't have DIOCGFWHEADS or DIOCGFWSECTORS, and % + * we know how to recover for the fd driver only. We could get the % + * media size and sector size from fdtype too, but shouldn't need them. % + */ % + if ((cruftmap & (NO_FWHEADS | NO_FDTYPE)) == NO_FWHEADS) { % + fwheads = fdtype.heads; % + cruftmap &= ~NO_FWHEADS; % } % - % - /* Maybe it's a floppy drive */ % - if (lp == NULL) { % - if (ioctl(fd, DIOCGMEDIASIZE, &ms) == -1) % - errx(1, "Cannot get disk size, %s", strerror(errno)); % - if (ioctl(fd, FD_GTYPE, &type) != -1) { % - dlp.d_secsize = 128 << type.secsize; % - dlp.d_nsectors = type.sectrac; % - dlp.d_ntracks = type.heads; % - dlp.d_secperunit = ms / dlp.d_secsize; % - lp = &dlp; % - hs = 0; % - } % + if ((cruftmap & (NO_FWSECTORS | NO_FDTYPE)) == NO_FWSECTORS) { % + fwsectors = fdtype.sectrac; % + cruftmap &= ~NO_FWSECTORS; % } % % - /* Maybe it's a fixed drive */ % - if (lp == NULL) { % - if (ioctl(fd, DIOCGDINFO, &dlp) == -1) { % - if (ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1) % - errx(1, "Cannot get sector size, %s", strerror(errno)); % - if (ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1) % - errx(1, "Cannot get number of sectors, %s", strerror(errno)); % - if (ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks)== -1) % - errx(1, "Cannot get number of heads, %s", strerror(errno)); % - dlp.d_secperunit = ms / dlp.d_secsize; % + /* Prefer to fall back to label info. */ % + if ((cruftmap & (NO_MEDIASIZE | NO_LABEL)) == NO_MEDIASIZE) { % + /* This shouldn't be needed. */ % + ms = label.d_secperunit * (off_t)label.d_secsize; % + cruftmap &= ~NO_MEDIASIZE; % + } % + if (cruftmap & NO_MEDIAOFFSET) { % +#ifdef NO_GEOM_LOSSAGE % + if (!(cruftmap | NO_LABEL)) { % + /* % + * XXX: lost non-GEOM code that handled this. The label info or % + * currently implemented primitive ioctls suffice for most file % + * systems, but msdosfs wants the absolute disk offset for one % + * thing (the number of hidden sectors). We can still use the old % + * code plus yet more compatibility cruft. In the GEOM case, GEOM % + * sysctl output must be parsed as in libdisk, or perhaps libdisk % + * can be used. libdisk takes a measly 300-400 lines and doesn't % + * seem to support more than the 2 layers (slice/partition) needed % + * for i386's, and demonstrates that xml is too hard to use by not % + * using it. % + * % + * Strangely, GEOM's breakage of compatibility for labels makes it % + * easy to determine the absolute disk offset here in some cases: % + * GEOM returns raw disk offsets in label.d_partitions[part].p_offset; % + * these already include the slice offset if the label is backwards % + * compatible, and we can determine if it is backwards compatible % + * by looking at the offset of the raw partition (until GEOM breaks % + * compatibility of that too). We would still need messy parsing % + * of the disk name to determine its partition number, if any. % + */ % + mo = ds.dss_slices[slice].ds_offset * (off_t)label.d_secsize; % + mo += label.d_partitions[part].p_offset * (off_t)label.d_secsize; % + cruftmap &= ~NO_MEDIAOFFSET; % } % +#else % + mo = 0; % + cruftmap &= ~NO_MEDIAOFFSET; % +#endif % + } % + if ((cruftmap & (NO_SECTORSIZE | NO_LABEL)) == NO_SECTORSIZE) { % + /* This shouldn't be needed. */ % + secsize = label.d_secsize; % + cruftmap &= ~NO_SECTORSIZE; % + } % + if ((cruftmap & (NO_HEADS | NO_LABEL)) == NO_HEADS) { % + heads = label.d_ntracks; % + cruftmap &= ~NO_HEADS; % + } % + if ((cruftmap & (NO_SECPERTRACK | NO_LABEL)) == NO_SECPERTRACK) { % + secpertrack = label.d_nsectors; % + cruftmap &= ~NO_SECPERTRACK; % + } % % - hs = (ms / dlp.d_secsize) - dlp.d_secperunit; % - lp = &dlp; % + /* % + * Fall back to "firmware" heads and sectors. % + * % + * XXX: this is quite broken, since we want the BIOS numbers, not the % + * firmware ones. GEOM has broken support for determining the BIOS % + * numbers in fdisk(8) and sysinstall(8) even more by changing things % + * to supply and use only the firmware numbers. Here we have a % + * preferred fallback to the numbers in the label, which can at least % + * be edited to give the BIOS numbers if they don't have them already. % + * Old labels defaulted to having BIOS numbers if possible, but GEOM % + * has got at new labels. % + */ % + if ((cruftmap & (NO_HEADS | NO_FWHEADS)) == NO_HEADS) { % + heads = fwheads; % + cruftmap &= ~NO_HEADS; % } % + if ((cruftmap & (NO_SECPERTRACK | NO_FWSECTORS)) == NO_SECPERTRACK) { % + secpertrack = fwsectors; % + cruftmap &= ~NO_SECPERTRACK; % + } % + % + /* % + * XXX this is too strict. We don't necessarily need the full disk % + * type, since we may have specified parts of it on the command line. % + * % + * Also, we don't support specifying the disk type in the normal way % + * (-T option in newfs). % + */ % + if ((cruftmap & (NO_MEDIASIZE | NO_MEDIAOFFSET | NO_SECTORSIZE | % + NO_HEADS | NO_SECPERTRACK)) != 0) % + warnx("%s: can't determine disk info; disk type must be specified", % + fname); % % if (bpb->bps == 0) % - bpb->bps = ckgeom(fname, lp->d_secsize, "bytes/sector"); % + bpb->bps = ckgeom(fname, secsize, "bytes/sector"); % if (bpb->spt == 0) % - bpb->spt = ckgeom(fname, lp->d_nsectors, "sectors/track"); % + bpb->spt = ckgeom(fname, secpertrack, "sectors/track"); % if (bpb->hds == 0) % - bpb->hds = ckgeom(fname, lp->d_ntracks, "drive heads"); % + bpb->hds = ckgeom(fname, heads, "drive heads"); % if (bpb->bsec == 0) % - bpb->bsec = lp->d_secperunit; % + bpb->bsec = ms / secsize; % if (bpb->hid == 0) % - bpb->hid = hs; % + bpb->hid = mo / secsize; % } % % @@ -802,5 +911,5 @@ % errx(1, "%s: no default %s", fname, msg); % if (val > MAXU16) % - errx(1, "%s: illegal %s %d", fname, msg, val); % + errx(1, "%s: illegal %s value %u", fname, msg, val); % return val; % } Bruce From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 14:37:38 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99AD716A400; Thu, 21 Feb 2008 14:37:38 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id E9F9C13C448; Thu, 21 Feb 2008 14:37:37 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id B3CDC43D995; Thu, 21 Feb 2008 16:37:36 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMIl64jZnwjr; Thu, 21 Feb 2008 16:37:36 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 2A1C543D699; Thu, 21 Feb 2008 16:37:36 +0200 (EET) Message-ID: <47BD8CAF.9090908@icyb.net.ua> Date: Thu, 21 Feb 2008 16:37:35 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: Bruce Evans References: <47B81D07.7090208@icyb.net.ua> <47BD6F39.7080105@icyb.net.ua> <20080222005213.W5655@besplex.bde.org> In-Reply-To: <20080222005213.W5655@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: newfs_msdos and dvd-ram (fwsectors, fwheads) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 14:37:38 -0000 on 21/02/2008 16:27 Bruce Evans said the following: > On Thu, 21 Feb 2008, Andriy Gapon wrote: > >> on 17/02/2008 13:39 Andriy Gapon said the following: >>> Should newfs_msdos be able to work on "whole" cdX/acdX device ? >>> [ufs/ffs] newfs can do it. >>> But with newfs_msdos I had to run disklabel first and then I could >>> create a filesystem on cdXa, but I couldn't do it on the whole disk. >> It seems that the reason for this newfs_msdos behavior is in the >> following lines: >> if (ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1) >> errx(1, "Cannot get sector size, %s", strerror(errno)); >> if (ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1) >> errx(1, "Cannot get number of sectors, %s", strerror(errno)); >> if (ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks)== -1) >> errx(1, "Cannot get number of heads, %s", strerror(errno)); >> >> While a failure to get sector size is a serious situation indeed, number >> of sectors per track and number of heads are just relics of the past and >> are not applicable to all types of should-be-supported media. >> What's even more funny is that those values can be set via command line >> options and in that case values from ioctl are not used at all. > > Also, it needs the BIOS geometry, but has been broken to ask for, and Bruce, you lost me after this. I understand that you speak about a general case, but is there a "BIOS geometry" for DVD-RAM disk ? Would any information about physical structure of DVD-RAM disk prove useful for FAT on it ? I thought that all those CHS parameters were useful only in times when CHS was the disk access mode (and maybe for performance optimizations). I don't see how those parameters can be of any real use now. P.S. I must declare that I know zero about FAT. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 14:56:19 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A98816A406; Thu, 21 Feb 2008 14:56:19 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.freebsd.org (Postfix) with ESMTP id D956213C4E7; Thu, 21 Feb 2008 14:56:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1LEuEZS016153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 01:56:16 +1100 Date: Fri, 22 Feb 2008 01:56:14 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Andriy Gapon In-Reply-To: <47BD8CAF.9090908@icyb.net.ua> Message-ID: <20080222014649.X29998@delplex.bde.org> References: <47B81D07.7090208@icyb.net.ua> <47BD6F39.7080105@icyb.net.ua> <20080222005213.W5655@besplex.bde.org> <47BD8CAF.9090908@icyb.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: newfs_msdos and dvd-ram (fwsectors, fwheads) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 14:56:19 -0000 On Thu, 21 Feb 2008, Andriy Gapon wrote: > on 21/02/2008 16:27 Bruce Evans said the following: >> On Thu, 21 Feb 2008, Andriy Gapon wrote: >> >>> on 17/02/2008 13:39 Andriy Gapon said the following: >>>> Should newfs_msdos be able to work on "whole" cdX/acdX device ? >>>> [ufs/ffs] newfs can do it. >>>> But with newfs_msdos I had to run disklabel first and then I could >>>> create a filesystem on cdXa, but I couldn't do it on the whole disk. >>> It seems that the reason for this newfs_msdos behavior is in the >>> following lines: >>> if (ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1) >>> errx(1, "Cannot get sector size, %s", strerror(errno)); >>> if (ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1) >>> errx(1, "Cannot get number of sectors, %s", strerror(errno)); >>> if (ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks)== -1) >>> errx(1, "Cannot get number of heads, %s", strerror(errno)); >>> >>> While a failure to get sector size is a serious situation indeed, number >>> of sectors per track and number of heads are just relics of the past and >>> are not applicable to all types of should-be-supported media. >>> What's even more funny is that those values can be set via command line >>> options and in that case values from ioctl are not used at all. >> >> Also, it needs the BIOS geometry, but has been broken to ask for, and > you lost me after this. I understand that you speak about a general > case, but is there a "BIOS geometry" for DVD-RAM disk ? Probably not. Docs say "for interrupt 0x13... only relevant for media that have a geometry". > Would any information about physical structure of DVD-RAM disk prove > useful for FAT on it ? The geometry fields might only be used by the bootstrap even on media that has a geometry. Since newfs_msdos writes a dummy bootstrap that doesn't support media accesses, we don't have to initialize them for that. > I thought that all those CHS parameters were useful only in times when > CHS was the disk access mode (and maybe for performance optimizations). > I don't see how those parameters can be of any real use now. That is probably correct, but since we don't control all uses of these fields, we should try to initialize them correctly. Bruce From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 20:53:56 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F67816A400; Thu, 21 Feb 2008 20:53:56 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id C70D713C46E; Thu, 21 Feb 2008 20:53:55 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 7F1C4744007; Thu, 21 Feb 2008 22:53:54 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id INKj9A8S7SWX; Thu, 21 Feb 2008 22:53:54 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 1FA35744006; Thu, 21 Feb 2008 22:53:52 +0200 (EET) Message-ID: <47BDE4D7.9000007@icyb.net.ua> Date: Thu, 21 Feb 2008 22:53:43 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-geom@freebsd.org, freebsd-fs@freebsd.org, freebsd-current@freebsd.org References: <47B81D07.7090208@icyb.net.ua> <47BD6F39.7080105@icyb.net.ua> In-Reply-To: <47BD6F39.7080105@icyb.net.ua> Content-Type: multipart/mixed; boundary="------------070705030706070407090301" Cc: Subject: Re: newfs_msdos and dvd-ram (fwsectors, fwheads) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 20:53:56 -0000 This is a multi-part message in MIME format. --------------070705030706070407090301 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Please found attached a patch to newfs_msdos that allows it to work on media for which CHS parameters do not make sense (e.g. DVD-RAM disks). First, newfs_msdos would not try to query parameters for which a user has provided override values via command line options. Second, newfs_msdos would fake values for CHS parameters like "sectors per track", "number of heads" which are not supported by the media and for which the user has not provided any values. These numbers/logic are borrowed from bsdlabel.c P.S. a line in the patch marked with XXX is a legacy of current code, not a new addition. P.S. this is not as extensive patch as that by Bruce Evans; its only merit is much smaller changeset versus current code/behavior. on 21/02/2008 14:31 Andriy Gapon said the following: > on 17/02/2008 13:39 Andriy Gapon said the following: >> Should newfs_msdos be able to work on "whole" cdX/acdX device ? >> [ufs/ffs] newfs can do it. >> But with newfs_msdos I had to run disklabel first and then I could >> create a filesystem on cdXa, but I couldn't do it on the whole disk. > > It seems that the reason for this newfs_msdos behavior is in the > following lines: > if (ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1) > errx(1, "Cannot get sector size, %s", strerror(errno)); > if (ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1) > errx(1, "Cannot get number of sectors, %s", strerror(errno)); > if (ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks)== -1) > errx(1, "Cannot get number of heads, %s", strerror(errno)); > > While a failure to get sector size is a serious situation indeed, number > of sectors per track and number of heads are just relics of the past and > are not applicable to all types of should-be-supported media. > What's even more funny is that those values can be set via command line > options and in that case values from ioctl are not used at all. > > Because those numbers are used by msdosfs on-disk structures we have to > provide some reasonable values for them even if they are meaningless > with respect to physical media organization. > An example of simple calculations can be found in bsdlabel.c. > I see two approaches: > 1) fake those properties in device drivers, primarily cd(4) and acd(4); > benefit: this can help other utilities besides newfs_msdos > 2) fake those properties in newfs_msdof; > benefit: this would help with other physical devices that can host > FAT; > > Or maybe do both. > -- Andriy Gapon --------------070705030706070407090301 Content-Type: text/x-patch; name="newfs-chs.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="newfs-chs.patch" --- newfs_msdos.c.orig 2008-02-21 21:35:00.000000000 +0200 +++ newfs_msdos.c 2008-02-21 21:56:13.000000000 +0200 @@ -739,13 +739,25 @@ /* Maybe it's a fixed drive */ if (lp == NULL) { if (ioctl(fd, DIOCGDINFO, &dlp) == -1) { - if (ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1) + if (bpb->bps == 0 && ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1) errx(1, "Cannot get sector size, %s", strerror(errno)); - if (ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1) - errx(1, "Cannot get number of sectors, %s", strerror(errno)); - if (ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks)== -1) - errx(1, "Cannot get number of heads, %s", strerror(errno)); + + /* XXX Should we use bpb->bps if it's set? */ dlp.d_secperunit = ms / dlp.d_secsize; + + if (bpb->spt == 0 && ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1) { + warnx("Cannot get number of sectors per track, %s", strerror(errno)); + dlp.d_nsectors = 63; + } + if (bpb->hds == 0 && ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks) == -1) { + warnx("Cannot get number of heads, %s", strerror(errno)); + if (dlp.d_secperunit <= 63*1*1024) + dlp.d_ntracks = 1; + else if (dlp.d_secperunit <= 63*16*1024) + dlp.d_ntracks = 16; + else + dlp.d_ntracks = 255; + } } hs = (ms / dlp.d_secsize) - dlp.d_secperunit; --------------070705030706070407090301-- From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 22:33:40 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF14916A403; Thu, 21 Feb 2008 22:33:40 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6EA8F13C45E; Thu, 21 Feb 2008 22:33:40 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 2E2FC1710A; Thu, 21 Feb 2008 22:33:39 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m1LDRqGW000890; Thu, 21 Feb 2008 13:27:52 GMT (envelope-from phk@critter.freebsd.dk) To: Andriy Gapon From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 21 Feb 2008 14:31:53 +0200." <47BD6F39.7080105@icyb.net.ua> Date: Thu, 21 Feb 2008 13:27:52 +0000 Message-ID: <889.1203600472@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: newfs_msdos and dvd-ram (fwsectors, fwheads) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 22:33:40 -0000 In message <47BD6F39.7080105@icyb.net.ua>, Andriy Gapon writes: >on 17/02/2008 13:39 Andriy Gapon said the following: >I see two approaches: >1) fake those properties in device drivers, primarily cd(4) and acd(4); > benefit: this can help other utilities besides newfs_msdos No. The geom attributes are provided if they are available only. It is the responsibility of the application code to decide and handle their absence. >2) fake those properties in newfs_msdof; > benefit: this would help with other physical devices that can host > FAT; This is the way to do it, but it might make sense to make a library routine do it, to get consistent behaviour. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-fs@FreeBSD.ORG Thu Feb 21 22:52:18 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5891516A404; Thu, 21 Feb 2008 22:52:18 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 876BA13C45A; Thu, 21 Feb 2008 22:52:17 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTP id AB70E28450; Fri, 22 Feb 2008 06:52:16 +0800 (CST) Received: from localhost (tarsier.geekcn.org [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id 69B3AEC4BC7; Fri, 22 Feb 2008 06:52:16 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id nuJwdOQA5ExF; Fri, 22 Feb 2008 06:52:11 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id B2FF4EC4B6C; Fri, 22 Feb 2008 06:52:09 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=TqTffa9FmLGDR8YZAc/FrSLl7Ff3ThVipBIAL+W5TVbiaLMzFIaZ9BgoGeHJhMZTe alvLo6c1P5GG/ZKr1Ucug== Message-ID: <47BE0096.3010109@delphij.net> Date: Thu, 21 Feb 2008 14:52:06 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20080122) MIME-Version: 1.0 To: d@delphij.net References: <47BBD864.3070905@delphij.net> In-Reply-To: <47BBD864.3070905@delphij.net> X-Enigmail-Version: 0.95.5 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------090507070102080306020007" Cc: freebsd-fs@freebsd.org, FreeBSD Current Subject: Re: [PATCH FOR REVIEW] fsck_ffs: Recover from catastrophic damage X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 22:52:18 -0000 This is a multi-part message in MIME format. --------------090507070102080306020007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is a revised version of patch. It adds a new '-C' flag to fsck_ffs(8), which causes fsck_ffs(8) to run in a new 'catastrophic recovery' mode, where more aggressive operations are done. All cg clearing operations are now hidden in '-C' mode, and a prompt is provided so that sysadmin can choose whether to clear the cg. Other changes: - Be more careful while resetting a cg. Set more fields; - Sanity check d_ino in pass2check(). Give fsck_ffs(8) an opportunity to recover from insane inode number provided by damaged directory entry. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHvgCWi+vbBBjt66ARAjrmAKCvDR/4wWiNp/k+9Jhz6YEhp9fFpgCeLyus /1BXVmFBI9S0fBdc3YOXmMw= =sE9G -----END PGP SIGNATURE----- --------------090507070102080306020007 Content-Type: text/plain; name="fsck.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fsck.diff" Index: fsck.h =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/fsck.h,v retrieving revision 1.37 diff -u -p -r1.37 fsck.h --- fsck.h 31 Oct 2006 22:06:56 -0000 1.37 +++ fsck.h 21 Feb 2008 22:01:44 -0000 @@ -270,6 +270,7 @@ char yflag; /* assume a yes response * int bkgrdflag; /* use a snapshot to run on an active system */ int bflag; /* location of alternate super block */ int debug; /* output debugging info */ +char catastrophicflag; /* run in catastrophic mode */ int cvtlevel; /* convert to newer file system format */ int bkgrdcheck; /* determine if background check is possible */ int bkgrdsumadj; /* whether the kernel have ability to adjust superblock summary */ @@ -335,6 +336,7 @@ void cacheino(union dinode *dp, ino_t i void catch(int); void catchquit(int); int changeino(ino_t dir, const char *name, ino_t newnum); +void check_cgmagic(int cg, struct cg *cgp); int chkrange(ufs2_daddr_t blk, int cnt); void ckfini(int markclean); int ckinode(union dinode *dp, struct inodesc *); Index: fsck_ffs.8 =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/fsck_ffs.8,v retrieving revision 1.34 diff -u -p -r1.34 fsck_ffs.8 --- fsck_ffs.8 20 Sep 2005 08:02:38 -0000 1.34 +++ fsck_ffs.8 21 Feb 2008 22:26:08 -0000 @@ -38,7 +38,7 @@ .Nd file system consistency check and interactive repair .Sh SYNOPSIS .Nm -.Op Fl BFpfny +.Op Fl BCFpfny .Op Fl b Ar block .Op Fl c Ar level .Op Fl m Ar mode @@ -175,6 +175,26 @@ Use the block specified immediately afte the super block for the file system. An alternate super block is usually located at block 32 for UFS1, and block 160 for UFS2. +.It Fl C +Run +.Nm +in 'catastrophic recovery' mode, which will enable certain aggressive +operations that can make +.Nm +to survive with file systems that has very serious data damage, which +is an useful last resort when on disk data damage is very serious +and causes +.Nm +to crash otherwise. Be +.Em very careful +using this flag, is dangerous if there are data transmission hazards +because a false positive cylinder group magic number mismatch could +cause +.Em irrevertible data loss! +.Pp +This option implies the +.Fl f +flag. .It Fl c Convert the file system to the specified level. Note that the level of a file system can only be raised. Index: fsutil.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/fsutil.c,v retrieving revision 1.26 diff -u -p -r1.26 fsutil.c --- fsutil.c 31 Oct 2006 22:06:56 -0000 1.26 +++ fsutil.c 21 Feb 2008 22:47:08 -0000 @@ -301,7 +301,7 @@ ckfini(int markclean) if (havesb && cursnapshot == 0 && sblock.fs_magic == FS_UFS2_MAGIC && sblk.b_bno != sblock.fs_sblockloc / dev_bsize && !preen && reply("UPDATE STANDARD SUPERBLOCK")) { - sblk.b_bno = sblock.fs_sblockloc / dev_bsize; + sblk.b_bno = SBLOCK_UFS2 / dev_bsize; sbdirty(); flush(fswritefd, &sblk); } @@ -418,6 +418,32 @@ blwrite(int fd, char *buf, ufs2_daddr_t } /* + * Check cg's magic number. If catastrophic mode is enabled and the cg's + * magic number is bad, offer an option to clear the whole cg. + */ +void +check_cgmagic(int cg, struct cg *cgp) +{ + + if (!cg_chkmagic(cgp)) { + pwarn("CG %d: BAD MAGIC NUMBER\n", cg); + if (catastrophicflag) { + if (reply("CLEAR CG")) { + memset(cgp, 0, (size_t)sblock.fs_cgsize); + cgp->cg_initediblk = sblock.fs_ipg; + cgp->cg_old_niblk = sblock.fs_ipg; + cgp->cg_old_ncyl = sblock.fs_old_cpg; + cgp->cg_cgx = cg; + cgp->cg_niblk = sblock.fs_ipg; + cgp->cg_ndblk = sblock.fs_size - cgbase(&sblock, cg); + cgp->cg_magic = CG_MAGIC; + } + } else + printf("YOU MAY NEED TO RERUN FSCK WITH -C IF IT CRASHED.\n"); + } +} + +/* * allocate a data block with the specified number of fragments */ ufs2_daddr_t @@ -441,8 +467,7 @@ allocblk(long frags) } cg = dtog(&sblock, i + j); getblk(&cgblk, cgtod(&sblock, cg), sblock.fs_cgsize); - if (!cg_chkmagic(cgp)) - pfatal("CG %d: BAD MAGIC NUMBER\n", cg); + check_cgmagic(cg, cgp); baseblk = dtogd(&sblock, i + j); for (k = 0; k < frags; k++) { setbmap(i + j + k); Index: inode.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/inode.c,v retrieving revision 1.38 diff -u -p -r1.38 inode.c --- inode.c 31 Oct 2006 22:06:56 -0000 1.38 +++ inode.c 21 Feb 2008 21:56:27 -0000 @@ -617,8 +617,7 @@ allocino(ino_t request, int type) return (0); cg = ino_to_cg(&sblock, ino); getblk(&cgblk, cgtod(&sblock, cg), sblock.fs_cgsize); - if (!cg_chkmagic(cgp)) - pfatal("CG %d: BAD MAGIC NUMBER\n", cg); + check_cgmagic(cg, cgp); setbit(cg_inosused(cgp), ino % sblock.fs_ipg); cgp->cg_cs.cs_nifree--; switch (type & IFMT) { Index: main.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/main.c,v retrieving revision 1.47 diff -u -p -r1.47 main.c --- main.c 19 Sep 2007 01:24:19 -0000 1.47 +++ main.c 21 Feb 2008 22:02:42 -0000 @@ -81,7 +81,8 @@ main(int argc, char *argv[]) sync(); skipclean = 1; - while ((ch = getopt(argc, argv, "b:Bc:dfFm:npy")) != -1) { + catastrophicflag = 0; + while ((ch = getopt(argc, argv, "b:Bc:CdfFm:npy")) != -1) { switch (ch) { case 'b': skipclean = 0; @@ -105,6 +106,10 @@ main(int argc, char *argv[]) debug++; break; + case 'C': + catastrophicflag = 1; + /* FALLTHROUGH */ + case 'f': skipclean = 0; break; Index: pass1.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/pass1.c,v retrieving revision 1.43 diff -u -p -r1.43 pass1.c --- pass1.c 8 Oct 2004 20:44:47 -0000 1.43 +++ pass1.c 20 Feb 2008 07:13:53 -0000 @@ -93,9 +93,11 @@ pass1(void) inumber = c * sblock.fs_ipg; setinodebuf(inumber); getblk(&cgblk, cgtod(&sblock, c), sblock.fs_cgsize); - if (sblock.fs_magic == FS_UFS2_MAGIC) + if (sblock.fs_magic == FS_UFS2_MAGIC) { inosused = cgrp.cg_initediblk; - else + if (inosused > sblock.fs_ipg) + inosused = sblock.fs_ipg; + } else inosused = sblock.fs_ipg; if (got_siginfo) { printf("%s: phase 1: cyl group %d of %d (%d%%)\n", Index: pass2.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/pass2.c,v retrieving revision 1.26 diff -u -p -r1.26 pass2.c --- pass2.c 8 Oct 2004 20:44:47 -0000 1.26 +++ pass2.c 21 Feb 2008 22:31:03 -0000 @@ -242,6 +242,8 @@ pass2check(struct inodesc *idesc) /* * check for "." */ + if (dirp->d_ino > maxino) + goto chk2; if (idesc->id_entryno != 0) goto chk1; if (dirp->d_ino != 0 && strcmp(dirp->d_name, ".") == 0) { Index: setup.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/setup.c,v retrieving revision 1.50 diff -u -p -r1.50 setup.c --- setup.c 31 Oct 2006 22:06:56 -0000 1.50 +++ setup.c 20 Feb 2008 07:13:27 -0000 @@ -349,7 +349,7 @@ readsb(int listerr) sblock.fs_sblockloc == sblock_try[i])) && sblock.fs_ncg >= 1 && sblock.fs_bsize >= MINBSIZE && - sblock.fs_bsize >= sizeof(struct fs)) + sblock.fs_sbsize >= roundup(sizeof(struct fs), dev_bsize)) break; } if (sblock_try[i] == -1) { --------------090507070102080306020007-- From owner-freebsd-fs@FreeBSD.ORG Fri Feb 22 01:00:34 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A77C816A405; Fri, 22 Feb 2008 01:00:34 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1BD8713C4D9; Fri, 22 Feb 2008 01:00:33 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTP id 0AE7A2844E; Fri, 22 Feb 2008 09:00:32 +0800 (CST) Received: from localhost (tarsier.geekcn.org [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id B2F6AEC47B6; Fri, 22 Feb 2008 09:00:31 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id O6Ga7sVKDYkP; Fri, 22 Feb 2008 09:00:25 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 5E24CEC4781; Fri, 22 Feb 2008 09:00:24 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=btvnXK0h/u2NC1GrK6ItXnVwEUEdEzeGt1Kb+rZTiRCSFo4xR3HIznxQKlZozv8x2 4m5RQLGnnpUf0t8hwS2OA== Message-ID: <47BE1EA3.7030105@delphij.net> Date: Thu, 21 Feb 2008 17:00:19 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20080122) MIME-Version: 1.0 To: d@delphij.net References: <47BBD864.3070905@delphij.net> <47BE0096.3010109@delphij.net> In-Reply-To: <47BE0096.3010109@delphij.net> X-Enigmail-Version: 0.95.5 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------060303000807050602000802" Cc: freebsd-fs@freebsd.org, FreeBSD Current Subject: Re: [PATCH FOR REVIEW] fsck_ffs: Recover from catastrophic damage X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 01:00:34 -0000 This is a multi-part message in MIME format. --------------060303000807050602000802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xin LI wrote: > Here is a revised version of patch. Sorry for replying myself. I found a nit - the clear of cg is beyond the reach of later phases, so set rerun = 1 to advise the user that a rerun of fsck is necessary to make a full recover. No other functional chnages. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHvh6ii+vbBBjt66ARApvIAKDCTQ13lZCTnP3mHLrJtIs+dsvF2gCeIy3j lrJcQw30LubvVfiVm8y6cvs= =Wh3/ -----END PGP SIGNATURE----- --------------060303000807050602000802 Content-Type: text/plain; name="fsck.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fsck.diff" Index: fsck.h =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/fsck.h,v retrieving revision 1.37 diff -u -p -r1.37 fsck.h --- fsck.h 31 Oct 2006 22:06:56 -0000 1.37 +++ fsck.h 21 Feb 2008 22:01:44 -0000 @@ -270,6 +270,7 @@ char yflag; /* assume a yes response * int bkgrdflag; /* use a snapshot to run on an active system */ int bflag; /* location of alternate super block */ int debug; /* output debugging info */ +char catastrophicflag; /* run in catastrophic mode */ int cvtlevel; /* convert to newer file system format */ int bkgrdcheck; /* determine if background check is possible */ int bkgrdsumadj; /* whether the kernel have ability to adjust superblock summary */ @@ -335,6 +336,7 @@ void cacheino(union dinode *dp, ino_t i void catch(int); void catchquit(int); int changeino(ino_t dir, const char *name, ino_t newnum); +void check_cgmagic(int cg, struct cg *cgp); int chkrange(ufs2_daddr_t blk, int cnt); void ckfini(int markclean); int ckinode(union dinode *dp, struct inodesc *); Index: fsck_ffs.8 =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/fsck_ffs.8,v retrieving revision 1.34 diff -u -p -r1.34 fsck_ffs.8 --- fsck_ffs.8 20 Sep 2005 08:02:38 -0000 1.34 +++ fsck_ffs.8 21 Feb 2008 22:26:08 -0000 @@ -38,7 +38,7 @@ .Nd file system consistency check and interactive repair .Sh SYNOPSIS .Nm -.Op Fl BFpfny +.Op Fl BCFpfny .Op Fl b Ar block .Op Fl c Ar level .Op Fl m Ar mode @@ -175,6 +175,26 @@ Use the block specified immediately afte the super block for the file system. An alternate super block is usually located at block 32 for UFS1, and block 160 for UFS2. +.It Fl C +Run +.Nm +in 'catastrophic recovery' mode, which will enable certain aggressive +operations that can make +.Nm +to survive with file systems that has very serious data damage, which +is an useful last resort when on disk data damage is very serious +and causes +.Nm +to crash otherwise. Be +.Em very careful +using this flag, is dangerous if there are data transmission hazards +because a false positive cylinder group magic number mismatch could +cause +.Em irrevertible data loss! +.Pp +This option implies the +.Fl f +flag. .It Fl c Convert the file system to the specified level. Note that the level of a file system can only be raised. Index: fsutil.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/fsutil.c,v retrieving revision 1.26 diff -u -p -r1.26 fsutil.c --- fsutil.c 31 Oct 2006 22:06:56 -0000 1.26 +++ fsutil.c 22 Feb 2008 00:50:43 -0000 @@ -301,7 +301,7 @@ ckfini(int markclean) if (havesb && cursnapshot == 0 && sblock.fs_magic == FS_UFS2_MAGIC && sblk.b_bno != sblock.fs_sblockloc / dev_bsize && !preen && reply("UPDATE STANDARD SUPERBLOCK")) { - sblk.b_bno = sblock.fs_sblockloc / dev_bsize; + sblk.b_bno = SBLOCK_UFS2 / dev_bsize; sbdirty(); flush(fswritefd, &sblk); } @@ -418,6 +418,35 @@ blwrite(int fd, char *buf, ufs2_daddr_t } /* + * Check cg's magic number. If catastrophic mode is enabled and the cg's + * magic number is bad, offer an option to clear the whole cg. + */ +void +check_cgmagic(int cg, struct cg *cgp) +{ + + if (!cg_chkmagic(cgp)) { + pwarn("CG %d: BAD MAGIC NUMBER\n", cg); + if (catastrophicflag) { + if (reply("CLEAR CG")) { + memset(cgp, 0, (size_t)sblock.fs_cgsize); + cgp->cg_initediblk = sblock.fs_ipg; + cgp->cg_old_niblk = sblock.fs_ipg; + cgp->cg_old_ncyl = sblock.fs_old_cpg; + cgp->cg_cgx = cg; + cgp->cg_niblk = sblock.fs_ipg; + cgp->cg_ndblk = sblock.fs_size - cgbase(&sblock, cg); + cgp->cg_magic = CG_MAGIC; + cgdirty(); + printf("PLEASE RERUN FSCK.\n"); + rerun = 1; + } + } else + printf("YOU MAY NEED TO RERUN FSCK WITH -C IF IT CRASHED.\n"); + } +} + +/* * allocate a data block with the specified number of fragments */ ufs2_daddr_t @@ -441,8 +470,7 @@ allocblk(long frags) } cg = dtog(&sblock, i + j); getblk(&cgblk, cgtod(&sblock, cg), sblock.fs_cgsize); - if (!cg_chkmagic(cgp)) - pfatal("CG %d: BAD MAGIC NUMBER\n", cg); + check_cgmagic(cg, cgp); baseblk = dtogd(&sblock, i + j); for (k = 0; k < frags; k++) { setbmap(i + j + k); Index: inode.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/inode.c,v retrieving revision 1.38 diff -u -p -r1.38 inode.c --- inode.c 31 Oct 2006 22:06:56 -0000 1.38 +++ inode.c 21 Feb 2008 21:56:27 -0000 @@ -617,8 +617,7 @@ allocino(ino_t request, int type) return (0); cg = ino_to_cg(&sblock, ino); getblk(&cgblk, cgtod(&sblock, cg), sblock.fs_cgsize); - if (!cg_chkmagic(cgp)) - pfatal("CG %d: BAD MAGIC NUMBER\n", cg); + check_cgmagic(cg, cgp); setbit(cg_inosused(cgp), ino % sblock.fs_ipg); cgp->cg_cs.cs_nifree--; switch (type & IFMT) { Index: main.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/main.c,v retrieving revision 1.47 diff -u -p -r1.47 main.c --- main.c 19 Sep 2007 01:24:19 -0000 1.47 +++ main.c 21 Feb 2008 22:02:42 -0000 @@ -81,7 +81,8 @@ main(int argc, char *argv[]) sync(); skipclean = 1; - while ((ch = getopt(argc, argv, "b:Bc:dfFm:npy")) != -1) { + catastrophicflag = 0; + while ((ch = getopt(argc, argv, "b:Bc:CdfFm:npy")) != -1) { switch (ch) { case 'b': skipclean = 0; @@ -105,6 +106,10 @@ main(int argc, char *argv[]) debug++; break; + case 'C': + catastrophicflag = 1; + /* FALLTHROUGH */ + case 'f': skipclean = 0; break; Index: pass1.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/pass1.c,v retrieving revision 1.43 diff -u -p -r1.43 pass1.c --- pass1.c 8 Oct 2004 20:44:47 -0000 1.43 +++ pass1.c 20 Feb 2008 07:13:53 -0000 @@ -93,9 +93,11 @@ pass1(void) inumber = c * sblock.fs_ipg; setinodebuf(inumber); getblk(&cgblk, cgtod(&sblock, c), sblock.fs_cgsize); - if (sblock.fs_magic == FS_UFS2_MAGIC) + if (sblock.fs_magic == FS_UFS2_MAGIC) { inosused = cgrp.cg_initediblk; - else + if (inosused > sblock.fs_ipg) + inosused = sblock.fs_ipg; + } else inosused = sblock.fs_ipg; if (got_siginfo) { printf("%s: phase 1: cyl group %d of %d (%d%%)\n", Index: pass2.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/pass2.c,v retrieving revision 1.26 diff -u -p -r1.26 pass2.c --- pass2.c 8 Oct 2004 20:44:47 -0000 1.26 +++ pass2.c 21 Feb 2008 22:31:03 -0000 @@ -242,6 +242,8 @@ pass2check(struct inodesc *idesc) /* * check for "." */ + if (dirp->d_ino > maxino) + goto chk2; if (idesc->id_entryno != 0) goto chk1; if (dirp->d_ino != 0 && strcmp(dirp->d_name, ".") == 0) { Index: setup.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/setup.c,v retrieving revision 1.50 diff -u -p -r1.50 setup.c --- setup.c 31 Oct 2006 22:06:56 -0000 1.50 +++ setup.c 20 Feb 2008 07:13:27 -0000 @@ -349,7 +349,7 @@ readsb(int listerr) sblock.fs_sblockloc == sblock_try[i])) && sblock.fs_ncg >= 1 && sblock.fs_bsize >= MINBSIZE && - sblock.fs_bsize >= sizeof(struct fs)) + sblock.fs_sbsize >= roundup(sizeof(struct fs), dev_bsize)) break; } if (sblock_try[i] == -1) { --------------060303000807050602000802-- From owner-freebsd-fs@FreeBSD.ORG Sat Feb 23 16:43:51 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6407816A403 for ; Sat, 23 Feb 2008 16:43:51 +0000 (UTC) (envelope-from softsearch@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by mx1.freebsd.org (Postfix) with ESMTP id 2236613C457 for ; Sat, 23 Feb 2008 16:43:51 +0000 (UTC) (envelope-from softsearch@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so865401wxd.7 for ; Sat, 23 Feb 2008 08:43:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:reply-to:organization:x-priority:message-id:to:subject:mime-version:content-type:content-transfer-encoding; bh=JGFrSUdjYZBMMiIbs3ykr5YyAqI8pPBeuXnEiM3+2os=; b=soUkGZGMn7G80RUPKdUo4+PaFkes7GxLYnxxwSpt+ftudyciLHLuXlMC1mo7Cl8+zU7DSkjpDESpf85KAo4/R/z95cwmAXoEem6csBZ3ji61dvBx3pT5QNFTGu399QVBKmKPIpct3OLrNDk/VLbxxFdYgdUbfzYmo9HrNwWgJlg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:reply-to:organization:x-priority:message-id:to:subject:mime-version:content-type:content-transfer-encoding; b=pvwEdl548qNZottRXFJvt+MQ6TnN6pDS5e8ur68I9uW8H5/JlftkCe5R3AeHaf0bpHCBmqYjTILUG/tkqB6QmLrm7BGZaUal734EBbGqOpdiALKdpBpbzgUn580g8jewUmPsYo9nWrTlmf9Q73CXZ2BQZVAaliqMDpsngXkCgBs= Received: by 10.65.153.10 with SMTP id f10mr1318286qbo.34.1203783320597; Sat, 23 Feb 2008 08:15:20 -0800 (PST) Received: from ?81.200.127.6? ( [81.200.127.6]) by mx.google.com with ESMTPS id c24sm4662809ika.10.2008.02.23.08.15.18 (version=SSLv3 cipher=OTHER); Sat, 23 Feb 2008 08:15:19 -0800 (PST) Date: Sat, 23 Feb 2008 19:14:50 +0300 From: Michael Monashev Organization: SoftSearch.ru X-Priority: 3 (Normal) Message-ID: <825583928.20080223191450@gmail.com> To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Synchronization request failed (error=1) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Michael Monashev List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2008 16:43:51 -0000 Hi. I did: >gmirror forget root >gmirror list root Geom name: root State: COMPLETE Components: 1 Balance: split Slice: 4096 Flags: NONE GenID: 7 SyncID: 1 ID: 1926374852 Providers: 1. Name: mirror/root Mediasize: 134217216 (128M) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: da1s1a Mediasize: 134217728 (128M) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 7 SyncID: 1 ID: 600760959 >gmirror insert root /dev/da0s1a and got some errors in /var/log/messages: Feb 17 18:17:03 host2 kernel: GEOM_MIRROR: Device root: provider da0s1a detected. Feb 17 18:17:03 host2 kernel: GEOM_MIRROR: Device root: rebuilding provider da0s1a. Feb 17 18:17:05 host2 kernel: GEOM_MIRROR: Synchronization request failed (error=1). da0s1a[WRITE(offset=0, length=131072)] Feb 17 18:17:05 host2 kernel: GEOM_MIRROR: Device root: provider da0s1a disconnected. Feb 17 18:17:05 host2 kernel: GEOM_MIRROR: Device root: rebuilding provider da0s1a stopped. How to correct this error and make "gmirror insert root /dev/da0s1a"? FreeBSD 6.3-PRERELEASE >bsdlabel /dev/da0s1 # /dev/da0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 262144 0 4.2BSD 2048 16384 16392 b: 33554432 262144 swap c: 976768002 0 unused 0 0 # "raw" part, don't edit d: 524288 33816576 4.2BSD 2048 16384 32776 e: 41943040 34340864 4.2BSD 2048 16384 28528 f: 4194304 76283904 4.2BSD 2048 16384 28528 g: 41943040 80478208 4.2BSD 2048 16384 28528 h: 854346754 122421248 4.2BSD 2048 16384 28528 >bsdlabel /dev/da1s1 # /dev/da1s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 262144 0 4.2BSD 0 0 0 c: 46781217 0 unused 0 0 # "raw" part, don't edit d: 524288 262144 4.2BSD 0 0 0 e: 41800481 4980736 4.2BSD 0 0 0 f: 4194304 786432 4.2BSD 0 0 0 >mount /dev/mirror/root on / (ufs, local, noatime, synchronous) devfs on /dev (devfs, local) /dev/mirror/tmp on /tmp (ufs, asynchronous, local, noatime) /dev/mirror/usr2 on /usr (ufs, local, noatime, soft-updates) /dev/mirror/var on /var (ufs, local, noatime, soft-updates) /dev/mirror/home on /home (ufs, local, noatime, soft-updates) /dev/da0s1h on /opt (ufs, local, noatime, soft-updates) /dev/mirror/dbs on /opt1 (ufs, local, noatime, soft-updates) /dev/mirror/sites on /opt2 (ufs, local, noatime, soft-updates) devfs on /var/named/dev (devfs, local) -- Michael