[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-nfsv4
Subject:    Re: [nfsv4] NFS4ERR_CLID_INUSE when
From:       Trond Myklebust <trond.myklebust () fys ! uio ! no>
Date:       2004-12-15 2:04:45
Message-ID: 1103076285.3262.53.camel () lade ! trondhjem ! org
[Download RAW message or body]

ty den 14.12.2004 Klokka 17:19 (-0800) skreiv Mike Eisler:

> Unless you can interpose that libary between me and the kernel,
> you can't take my Kerberos, SPKM, LIPKEY, etc. creds from me
> and impersonate me. Just like, you can write a user level http
> client using a client library with SSL to try to access my amazon
> account, but unless you know my password or unless you
> can replace my firefox, it doesn't do you any good. I'm
> far more confident in your ability to switch -- without me
> noticing -- my firefox than to switch my kernel.

No, but all I need is a valid credential (any valid credential) in order
to be able to mess with your stateids and open_owners assuming that I
can guess them or sniff them off the wire. I believe that was the gist
of Bruce's complaint.

The reason is that stateids and open_owners are not tied to any
particular rpcsec_gss context or even to a particular principal as far
as the server is concerned. I don't even need access rights to the file
in order to mess with a client's open owner sequence id accounting. 

Are servers for instance checking that CLOSE, DELEGRETURN are
originating from the same client IP address as the initial OPEN, or the
SETCLIENTID? I don't believe Linux is...

Cheers,
  Trond

-- 
Trond Myklebust <trond.myklebust@fys.uio.no>


_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4


[prev in list] [next in list] [prev in thread] [next in thread]