[118] in The Cryptographic File System users list
Re: CFS goes unresponsive under NetBSD
daemon@ATHENA.MIT.EDU (Matt Blaze)
Mon Jan 25 13:56:00 1999
From owner-cfs-users@research.att.com Mon Jan 25 18:55:59 1999
Return-Path: <owner-cfs-users@research.att.com>
Delivered-To: cfs-mtg@bloom-picayune.mit.edu
Received: (qmail 20625 invoked from network); 25 Jan 1999 18:55:58 -0000
Received: from unknown (HELO mail-blue.research.att.com) (135.207.30.102)
by bloom-picayune.mit.edu with SMTP; 25 Jan 1999 18:55:58 -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 4C9C54CE9E; Mon, 25 Jan 1999 13:55:58 -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 NAA08835;
Mon, 25 Jan 1999 13:55:52 -0500 (EST)
Received: (from majordomo@localhost) by nsa.research.att.com (8.7.3/8.7.3) id NAA28717 for cfs-users-list; Mon, 25 Jan 1999 13:54:18 -0500 (EST)
X-Authentication-Warning: nsa.research.att.com: majordomo set sender to owner-cfs-users@nsa.research.att.com using -f
Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id NAA28713 for <cfs-users@nsa.research.att.com>; Mon, 25 Jan 1999 13:54:16 -0500 (EST)
Received: from nsa.research.att.com (root@nsa.research.att.com [135.207.24.155])
by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id NAA08811;
Mon, 25 Jan 1999 13:55:23 -0500 (EST)
Received: from nsa.research.att.com (mab@localhost.research.att.com [127.0.0.1]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id NAA28705; Mon, 25 Jan 1999 13:54:14 -0500 (EST)
Message-Id: <199901251854.NAA28705@nsa.research.att.com>
To: Frame@anon.lcs.mit.edu, 313@anon.lcs.mit.edu
Cc: cfs-users@research.att.com
Subject: Re: CFS goes unresponsive under NetBSD
In-reply-to: Your message of "25 Jan 1999 17:00:15 GMT."
<19990125170015.18789.qmail@nym.alias.net>
Date: Mon, 25 Jan 1999 13:54:14 -0500
From: Matt Blaze <mab@research.att.com>
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.
>
I am unable to reproduce this under BSDI 3.1 or 4.0 and netscape 4.4 or
4.7 - everything works fine for me.
>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?
>
You should make absolutely sure that you've exported /null only
to localhost, although exporting /null (rather than /) to the world
should be non-disasterous under most versions of mountd (and not
an issue at all if your machine isn't running a real NFS server).
>Any thoughts on performing short block handling (rather than padding)?
I've not found a better answer to this (for a file system) than what
CFS does, which adds an extra 8 bytes to files that aren't a multiple
of 8 bytes.
>
>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?
Again, I can't reproduce this. You can't mv across encrypted
directories because you'd have to decrypt and reencrypt, inside the
file system, but the filesystem doesn't have enough information at that
interface to understand what's going on and figure out how do do that.
I return EEXIST because there really isn't an appropriate return code
(there's no XMOUNT NFS return code). But cp shoudn't (and doesn't, in
my tests) cause this.
>
>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
