[jcifs] Re: SMB Signing

Michael B Allen mba2000 at ioplex.com
Mon Sep 8 19:00:35 EST 2003

>> However, I think we should move most of this into SmbSession. For one,
>> it's not clear to me that initSigning() should be called more than once
>> for each session. We can add an SmbSession member to the
>> ServerMessageBlock class that get's set in
>> SmbSession.send()/sendTransaction() to 'this' session. That way we can
>> access the session from within SmbTransport through req.session and put
>> all session specific state there like the macSigningKey, signSequence,
>> etc. We could also put the sign and varify routines in there since the
>> NPA
>> of interest is a member. We probably don't need the signingLock either.
>> Using multiple locks in the transport was the cause of that deadlock we
>> had.
> Sounds okay; you might have to fiddle with it a bit.  The signing is *kind
> of*
> per-session, but not really; after the initial setup on the transport
> (with
> the first session setup request) the sequence/key isn't reset until
> another
> NegProt comes in. This gets kind of funky, since we have multiple
> sessions
> over a single transport.  The mac signing key is established using the
> first
> user's NTLM response.  Subsequent session setup requests (even from other
> users)
> don't reset the mac signing -- it is still done using the first user's key
> (which is weird).

Oh. Well that changes everything. I thought a new key needed to be
generated for each user. I suppose SmbTransport is a good spot then.

> It also gets strange since multiple threads can be throwing stuff at us
> If the sequence gets screwed up, you'll get errors pretty quick (either
> locally, in the verify() method, or remotely via access exceptions).

I see. I'll take a closer look...

>> Currently I'm looking closely at docs/todo and thinking about a 0.8
>> release. I'll present my objectives on the list in a day or so. I'll add
>> this to that.
>> Mike
> Looking forward to it!  I've got a couple of minor items I'd like to see,
> so I'll see if they make the list.

The next release will focus on all the little (non-RPC) things that one
would expect jCIFS to have but for whatever reason were dropped by the
wayside such as RandomAccessFile, copyTo w/ extended attributes, DFS,
removing read-only when deleting a tree, setReadOnly, etc. By all means,
present your list.

Then I want to do another release just for house-cleaning like
consolodating/normalizing decoding/encoding rountines, getting rid of
PropertiesTree, making all properties static but arrange it so they can be
reloaded at runtime (e.g. for app servers). I suppose Config should
largely go away in theory.


More information about the jcifs mailing list