[jcifs] Re: SMB Signing

[eglass1 at comcast.net]

> 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).  When a negotiate() happens, the sequence and keys are reset
and initialized using the next session setup.

It also gets strange since multiple threads can be throwing stuff at us (that's
why I put separate sequence counters for signing and verifying; I had a single
counter, but it all fell apart under multithreading because I would get i.e. 2
consecutive requests and lose sequence).  The best way to test is to find a
server with signing enabled and send a couple of threads at it with requests
from multiple users, like:

final SmbFile f1 = new SmbFile("smb://DOM;testa:passwd@server/share/dir2/");
final SmbFile f2 = new SmbFile("smb://DOM;testb:pass2@server/share/dir/");
(new Thread() {
    public void run() {
        try {
            f1.listFiles();
            f2.listFiles();
            f1.listFiles();
            f1.listFiles();
            f2.listFiles();
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }
}).start();
(new Thread() {
    public void run() {
        try {
            f2.listFiles();
            f1.listFiles();
            f2.listFiles();
            f2.listFiles();
            f1.listFiles();
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }
}).start();


If the sequence gets screwed up, you'll get errors pretty quick (either
locally, in the verify() method, or remotely via access exceptions).

> 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.


Eric