On Mon, 2012-04-23 at 17:38 -0400, Chuck Lever wrote:
> On Apr 23, 2012, at 5:32 PM, Myklebust, Trond wrote:
>
> > On Mon, 2012-04-23 at 16:57 -0400, Chuck Lever wrote:
> >> On Apr 23, 2012, at 4:48 PM, Myklebust, Trond wrote:
> >>
> >>> On Mon, 2012-04-23 at 16:44 -0400, Chuck Lever wrote:
> >>>> Hi-
> >>>>
> >>>> I wish you had told me you were going to fix this too. I've been testing a fix for this for a couple weeks. Was going to post this afternoon. Shall I toss mine?
> >>>
> >>> I was hitting that BAD_SEQID storm during testing of the other open
> >>> fixes last week.
> >>
> >> Fair enough, but I announced I had a fix in my April 15 status report. Oh well.
> >>
> >> So, I decided that a timestamp would leak information about the client, so I'm using a simple counter instead. Would you consider that for your patch?
> >
> > How would a timestamp leak useful information? The server and anyone
> > monitoring the NFS traffic already knows at what time the open owner was
> > created to within a few milliseconds.
>
> It leaks the exact time as the client sees it. This is why time-based UUIDs are no longer considered safe.
..and file creation dates leak the exact time as the server sees it...
If you are using NFS on an untrusted network, then you should be using
RPCSEC_GSS with full privacy.
> But also, is it possible that a state_owner could be destroyed and created so quickly on a system with inadequate timestamp resolution, such that the new owner ID would not actually be different than the previous one?
Caching all previously used uniquifiers on the LRU list for a while
takes care of that problem (see the third patch in my series).
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
