[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
>> 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
> Sounds okay; you might have to fiddle with it a bit. The signing is *kind
> per-session, but not really; after the initial setup on the transport
> the first session setup request) the sequence/key isn't reset until
> NegProt comes in. This gets kind of funky, since we have multiple
> over a single transport. The mac signing key is established using the
> user's NTLM response. Subsequent session setup requests (even from other
> 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.
> 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