[116] in The Cryptographic File System users list
CFS goes unresponsive under NetBSD
daemon@ATHENA.MIT.EDU (Frame@anon.lcs.mit.edu,313@anon.lc)
Mon Jan 25 12:04:06 1999
From owner-cfs-users@research.att.com Mon Jan 25 17:04:06 1999
Return-Path: <owner-cfs-users@research.att.com>
Delivered-To: cfs-mtg@bloom-picayune.mit.edu
Received: (qmail 18677 invoked from network); 25 Jan 1999 17:04:03 -0000
Received: from unknown (HELO mail-blue.research.att.com) (135.207.30.102)
by bloom-picayune.mit.edu with SMTP; 25 Jan 1999 17:04:03 -0000
Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32])
by mail-blue.research.att.com (Postfix) with ESMTP
id CA5064CE1A; Mon, 25 Jan 1999 12:04:02 -0500 (EST)
Received: from nsa.research.att.com (majordomo@nsa.research.att.com [135.207.24.155])
by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id MAA05246;
Mon, 25 Jan 1999 12:03:22 -0500 (EST)
Received: (from majordomo@localhost) by nsa.research.att.com (8.7.3/8.7.3) id LAA28146 for cfs-users-list; Mon, 25 Jan 1999 11:59:09 -0500 (EST)
X-Authentication-Warning: nsa.research.att.com: majordomo set sender to owner-cfs-users@nsa.research.att.com using -f
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id LAA28142 for <cfs-users@nsa.research.att.com>; Mon, 25 Jan 1999 11:59:07 -0500 (EST)
Delivered-To: cfs-users@research.att.com
Received: from anon.lcs.mit.edu (anon.lcs.mit.edu [18.26.0.254])
by mail-blue.research.att.com (Postfix) with SMTP for <cfs-users@research.att.com>
id 19EC44CE1A; Mon, 25 Jan 1999 12:00:16 -0500 (EST)
Date: 25 Jan 1999 17:00:15 -0000
Message-ID: <19990125170015.18789.qmail@nym.alias.net>
To: cfs-users@research.att.com
From: lcs Mixmaster Remailer <mix@anon.lcs.mit.edu>
X-Comment1: This message did not originate from the
X-Comment2: above address. It was automatically remailed
X-Comment3: by an anonymous mail service. Please report
X-Comment4: problems or inappropriate use to
X-Comment5: <postmaster@anon.lcs.mit.edu>
Subject: CFS goes unresponsive under NetBSD
From: Frame@anon.lcs.mit.edu, 313@anon.lcs.mit.edu
Sender: owner-cfs-users@research.att.com
Precedence: bulk
I found that I can tickle a bug in CFS or NetBSD by placing Netscape
history.db file on the crypted drive. This causes cfsd to go into a
strange state; I can't kill it, even with SIGKILL; ps reports it as
being in state D+. Any process which attempt to stat /crypt hangs.
System gets very slow. Some kernel messages about NFS not responding.
I built debugging version, found that last request was innocuous
getattr request, like many before it. Probe with rpcinfo times out.
Older CFS had mention of inode "creation time" which is confusing.
This mention is removed from latest CFS (1.4.0 Beta 2).
Makefile should mention you can define NO_DEFAULT_NAME to prevent
cattach from guessing /crypt name based on last component of encrypted
path.
I am wondering if there is security issue with exporting /null; will
this make / vulnerable to NFS attack?
Any thoughts on performing short block handling (rather than padding)?
Just a heads-up, you can't cp from one decrypted (/crypt/foo)
directory to another (/crypt/bar). It gives EEXIST. I guess because
cfsd has single thread?
NetBSD version calls daemon(3) which forks so printed PID is usually
(cfsd_pid - 1).
I will post my NetBSD diffs to CFS 1.3 and CFS 1.4.0 Beta 2 soon.
Frame 313
