[155] in The Cryptographic File System users list
Re: .ANON_xx and nuisance users
daemon@ATHENA.MIT.EDU (Matt Blaze)
Fri Oct 8 05:13:09 1999
From owner-cfs-users@nsa.research.att.com Fri Oct 08 09:13:08 1999
Return-Path: <owner-cfs-users@nsa.research.att.com>
Delivered-To: cfs-mtg@CHARON2.mit.edu
Received: (qmail 8035 invoked from network); 8 Oct 1999 09:13:08 -0000
Received: from h-135-207-30-103.research.att.com (HELO mail-green.research.att.com) (135.207.30.103)
by charon2.mit.edu with SMTP; 8 Oct 1999 09:13:08 -0000
Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32])
by mail-green.research.att.com (Postfix) with ESMTP
id 3E71A1E044; Fri, 8 Oct 1999 05:13:08 -0400 (EDT)
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 FAA17746;
Fri, 8 Oct 1999 05:13:07 -0400 (EDT)
Received: (from majordomo@localhost) by nsa.research.att.com (8.7.3/8.7.3) id FAA19482 for cfs-users-list; Fri, 8 Oct 1999 05:12:54 -0400 (EDT)
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 FAA19478 for <cfs-users@nsa.research.att.com>; Fri, 8 Oct 1999 05:12:53 -0400 (EDT)
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 FAA17736;
Fri, 8 Oct 1999 05:12:35 -0400 (EDT)
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 FAA19471; Fri, 8 Oct 1999 05:12:29 -0400 (EDT)
Message-Id: <199910080912.FAA19471@nsa.research.att.com>
To: Nicholas Brawn <ncb@zip.com.au>
Cc: cfs-users@research.att.com
Subject: Re: .ANON_xx and nuisance users
In-reply-to: Your message of "Fri, 08 Oct 1999 18:17:03 +1000."
<Pine.LNX.4.10.9910081803150.6980-100000@zipperii.zip.com.au>
Date: Fri, 08 Oct 1999 05:12:28 -0400
From: Matt Blaze <mab@research.att.com>
Sender: owner-cfs-users@research.att.com
Precedence: bulk
Unfortunately, none of the answers to this are entirely satisfactory.
The .ANON_* names are placeholders in directory listings intended to allow
you to detach a directory even if you don't know the name under
which it was attached; there's actually extra code in there to
include this as a feature. Without this ability, if you forget
the name of a hidden attach, it will just sit there forever, or at
least until the cfsd is killed.
The detach code (in cfs_adm.c) doesn't include a test for userid matching
because there's no way to get meaningful, reliable data here; rpc fields
are filled in by the (user-level) cdetach command, so a nuisance user
could just fill in any uid she wanted.
There are a few solutions:
- Include a uid test in detach, and make cdetach a suid root process that
binds to a priviledged port to enforce the use of a trusted cdetach program.
I dislike this; setuid programs scare me and this seems like too small
a gain to justify overcoming this fear.
- Get rid of the mechanism for detaching .ANON_* names. This would have
the effect of making .* names last forever if they are forgotten about;
the only way to free up the resources they consume (which can be significant
in cfsd) is to kill and restart cfsd. If you want to do this, just
comment out
if (strncmp(ap->name,".ANON_",6) == 0) {
i = atoi(&ap->name[6]);
if ((i>0) && (i<NINSTANCES) && (instances[i]!=NULL))
goto found;
}
in the admproc_detach_2 function in cfs_adm.c .
- Just live with it, and tell people never to run cfs on a
machine that others have access to and that they don't fully
control. That, obviously, is the solution I picked...
Unfortunately, there's no easy way to make it do what you
think it should do (which is to allow the attaching user or root
to detach it with the .anon name, and noone else), at least not
without making cdetach setuid root (which I want to resist).
-matt
>Hi there. Before I raise my issue, two vital pieces of information:
>
>OS: FreeBSD (3.1)
>CFS Version: cfs-1.3.3.1
>
>To quote from cattach(1)'s manpage:
>
> Ordinarily, the names of all currently attached directo-
> ries can be obtained by listing the contents of /crypt
> (e.g., with ls(1)). If the specified name begins with a
> '.' (dot), however, cfsd will not include the name in
> directory listings.
>
>...
>
>The following is an example of the issue I have:
>
>ncb@gw:~$ ls -alF /crypt
>total 2
>drwxrwxrwx 4 root wheel 8192 Oct 8 17:57 ./
>drwxr-xr-x 20 root wheel 512 Oct 8 17:53 ../
>ncb@gw:~$ cattach /usr/local/crypt/ncb .test1234
>Key:
>ncb@gw:~$ ls -alF /crypt
>ls: .ANON_47: No such file or directory
>total 2
>drwxrwxrwx 4 root wheel 8192 Oct 8 18:06 ./
>drwxr-xr-x 20 root wheel 512 Oct 8 17:53 ../
>ncb@gw:~$ cd /crypt/.test1234
>ncb@gw:/crypt/.test1234$
>
>Meanwhile, Mallory is busy in his session being a nuisance:
>
>mallory@gw:~$ ls -alF /crypt
>ls: .ANON_47: No such file or directory
>total 2
>drwxrwxrwx 4 root wheel 8192 Oct 8 18:06 ./
>drwxr-xr-x 20 root wheel 512 Oct 8 17:53 ../
>mallory@gw:~$ cdetach .ANON_47
>mallory@gw:~$
>
>We go back to ncb's account:
>
>ncb@gw:/crypt/.test1234$ ls
>ls: .: Stale NFS file handle
>ncb@gw:/crypt/.test1234$
>
>The question is whether the .ANON_xx is an OS peculiarity, or is it a CFS
>issue. Regardless of what's to blame, is there a way to prevent this
>occuring. Lastly, is there a way to prevent illegitimate users detaching
>other users "sessions".
>
>Help in this matter would be appreciated.
>
>Nick
>
>--
>Email: ncb@zip.com.au (or) nicholas.brawn@hushmail.com
>Key fingerprint = 71C5 2EA8 903B 0BC4 8EEE 9122 7349 EADC 49C1 424E
>
