[108] in The Cryptographic File System users list
Re: cattach permission problem
daemon@ATHENA.MIT.EDU (Walter Haidinger)
Thu Oct 8 14:14:04 1998
From owner-cfs-users@research.att.com Thu Oct 08 18:14:03 1998
Return-Path: <owner-cfs-users@research.att.com>
Delivered-To: cfs-mtg@bloom-picayune.mit.edu
Received: (qmail 11333 invoked from network); 8 Oct 1998 18:14:02 -0000
Received: from unknown (HELO rumor.research.att.com) (192.20.225.9)
by bloom-picayune.mit.edu with SMTP; 8 Oct 1998 18:14:02 -0000
Received: from research.att.com ([135.207.30.100]) by rumor; Thu Oct 8 14:06:00 EDT 1998
Received: from amontillado.research.att.com ([135.207.24.32]) by research; Thu Oct 8 14:09:46 EDT 1998
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 OAA03507;
Thu, 8 Oct 1998 14:10:19 -0400 (EDT)
Received: (from majordomo@localhost) by nsa.research.att.com (8.7.3/8.7.3) id OAA06821 for cfs-users-list; Thu, 8 Oct 1998 14:00:59 -0400 (EDT)
X-Authentication-Warning: nsa.research.att.com: majordomo set sender to owner-cfs-users@nsa.research.att.com using -f
Received: from research.att.com (research.research.att.com [135.207.30.100]) by nsa.research.att.com (8.7.3/8.7.3) with SMTP id OAA06817 for <cfs-users@nsa.research.att.com>; Thu, 8 Oct 1998 14:00:56 -0400 (EDT)
Received: from mail.pgv.at ([194.118.8.250]) by research; Thu Oct 8 14:05:55 EDT 1998
Received: from banshee.pandora.at (p01.multi.pgv.at [194.118.8.132])
by mail.pgv.at (Netscape Messaging Server 3.5) with ESMTP
id AAD3F65 for <cfs-users@research.att.com>;
Thu, 8 Oct 1998 19:54:24 +0200
Received: from localhost (walter@localhost [127.0.0.1])
by banshee.pandora.at (8.8.8/8.8.8) with SMTP id MAA17993
for <cfs-users@research.att.com>; Thu, 8 Oct 1998 12:11:48 +0200
Date: Thu, 8 Oct 1998 12:11:48 +0200 (CEST)
From: Walter Haidinger <walter.haidinger@gmx.net>
X-Sender: walter@banshee.pandora.at
Reply-To: Walter Haidinger <walter.haidinger@gmx.net>
To: cfs-users@research.att.com
Subject: Re: cattach permission problem
In-Reply-To: <m0zQlfd-0008F6C@colnet.cmhnet.org>
Message-ID: <Pine.LNX.3.96.981008111612.11552D-100000@banshee.pandora.at>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-cfs-users@research.att.com
Precedence: bulk
On Wed, 7 Oct 1998, Rob Stampfli wrote:
> Not that I'd necessarily recommend this, but one way would be to give your
> client machine root access permissions in the "export" file on the server.
> I'm not sure how this is done under Linux, but on SunOS, for instance,
> if you add
>
> /home -access=x,root=x
>
> to the /etc/exports file on the system exporting /home, then machine x
> can mount /home and have full root privileges in it. I do this on a local
> LAN at home. I would consider it a security risk on a public LAN.
>
I added the following to /etc/exports and made nfsd and mountd reread it:
/ localhost(rw,no_root_squash,insecure)
which allows any user to mount the root directory read/write from any port
(insecure) while NOT mapping uid 0 to nobody (no_root_squash). So, this is
like accessing / regulary but through nfs. If root does
mount -t nfs localhost:/ /mnt
every user can access / through /mnt without with no change in rights.
[Yes, you grant everyone root access, but please read my question below.]
Unfortunatly this doesn't work. There must be still permission to
'others' to access the directory in order to cattach it.
Let me ask a question regarding the exports file:
Why do you believe that I have to export the root (or any other) directory
for cfsd to access it?
If /etc/exports consists of a single entry, the cfs hook `/nfs/.cfsfs',
I can still cattach any directory provided that others can access it too.
E.g.: If I export /home instead of / in the above example, I can still do
cattach /tmp/secure walter
while *not* being root although /tmp is *not* exported by /etc/exports.
So, think /etc/exports is not used by cfsd when searching for the
directory to mount via nfs.
Let me quote you first reply again:
: Look carefully at the permissions of the directories above the "secure"
: directory. Remember: on nfs mounted file systems, the program running
: as root (cfsd) really has the permissions of "nobody".
This would be solved by adding 'no_squash_root' in the exports file.
However, there seems to be no need for an exported directory at all...
: Although it (cfsd) can setuid() and masquerade as "walter", if there is
: any higher level directory that doesn't allow at least "execute"
: permission, you will get this error. And, remember, cfsd doesn't belong
: to the same "groups" as the walter user.
That makes sense if the following is true (please correct me if I'm
wrong):
User walter calls cattach which contacts cfsd. Next, cfsd masquerades as
'walter' and tries to cd to the directory which should be mounted. It
fails because the higher directories require group permissions which
walter is a member of, but not neither group is walter's primary [Assuming
that setuid only sets the users primary group id too, if any at all. I
really do not know how group rights are handled when setuid is called].
A solution would be having cfsd locating the directory as root and then
mounting it as (or for) walter.
Another possiblity would be if csfd would not do not only a setuid() but
also became a member of *all* groups the user is a member of too.
Is this possible or am I totally off track here?
> Since this is somewhat off topic, I'm not bothering to post to the cfs
> mail list.
Well, I think we're back to a cfsd topic which should go to the
mailinglist. I hope you agree.
Regards, Walter
--
Walter Haidinger <walter.haidinger@gmx.net>
Student of Electrical Engineering, University of Technology, Vienna, Austria
Address: Brunnerstrasse 6, A-3108 St.P"olten, Austria. Tel.: +43-2742-257191
Get my PGP public key from http://members.pgv.at/haidinger/pgp/pubkey.txt
or send email (body ignored) with the subject "[Request PGP public key]" to
<walthaid@unix.ict.tuwien.ac.at>. Mind case and brackets!
