Null pointer exception in ServerMessageBlock.java

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Null pointer exception in ServerMessageBlock.java

Jake Goulding
At line 212 of ServerMessageBlock.java, I get a Null Pointer Exception,
and I was hoping someone could help me figure it out.

I am using the ACL resolve patch found in the patches directory as I
strongly need the ability to get the usernames and groups for each file.
When I run it normally, I get the following exception:
jcifs.smb.SmbAuthException: Logon failure: unknown user name or bad
password.
        at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:499)
        at jcifs.smb.SmbTransport.send(SmbTransport.java:610)
        at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:269)
        at jcifs.smb.SmbSession.send(SmbSession.java:225)
        at jcifs.smb.SmbTree.treeConnect(SmbTree.java:147)
        at jcifs.smb.SmbFile.connect(SmbFile.java:792)
        at jcifs.smb.SmbFile.connect0(SmbFile.java:762)
        at jcifs.smb.SmbFileInputStream.<init>(SmbFileInputStream.java:72)
        at
jcifs.smb.TransactNamedPipeInputStream.<init>(TransactNamedPipeInputStream.java:38)
        at
jcifs.smb.SmbNamedPipe.getNamedPipeInputStream(SmbNamedPipe.java:166)
        at jcifs.smb.RpcTransport.attach(RpcTransport.java:91)
        at rpc.Stub.attach(Stub.java:105)
        at rpc.Stub.call(Stub.java:110)
        at jcifs.rpc.LsaRPC.openPolicy(LsaRPC.java:62)
        at jcifs.rpc.LsaRPC.lookupSids(LsaRPC.java:94)
        at jcifs.smb.SmbFile.getSecurity(SmbFile.java:2528)

Which I believe is the same problem as discussed here (guest account
being used):
http://thread.gmane.org/gmane.network.samba.java/5273/focus=5304

However, if I set the properties jcifs.smb.client.{domain, username,
password} before calling the appropriate functions I get this error:
Exception in thread "main" java.lang.NullPointerException
        at
jcifs.smb.ServerMessageBlock.writeString(ServerMessageBlock.java:212)
        at
jcifs.smb.ServerMessageBlock.writeString(ServerMessageBlock.java:201)
        at
jcifs.smb.SmbComNTCreateAndX.writeBytesWireFormat(SmbComNTCreateAndX.java:170)
        at
jcifs.smb.AndXServerMessageBlock.writeAndXWireFormat(AndXServerMessageBlock.java:101)
        at
jcifs.smb.AndXServerMessageBlock.encode(AndXServerMessageBlock.java:65)
        at jcifs.smb.SmbTransport.doSend(SmbTransport.java:402)
        at jcifs.util.transport.Transport.sendrecv(Transport.java:70)
        at jcifs.smb.SmbTransport.send(SmbTransport.java:602)
        at jcifs.smb.SmbSession.send(SmbSession.java:231)
        at jcifs.smb.SmbTree.send(SmbTree.java:102)
        at jcifs.smb.SmbFile.send(SmbFile.java:688)
        at jcifs.smb.SmbFile.open0(SmbFile.java:828)
        at jcifs.smb.SmbFile.open(SmbFile.java:846)
        at
jcifs.smb.TransactNamedPipeOutputStream.write(TransactNamedPipeOutputStream.java:61)
        at jcifs.smb.RpcTransport.send(RpcTransport.java:107)
        at
rpc.DefaultConnection.transmitFragment(DefaultConnection.java:107)
        at rpc.DefaultConnection.transmit(DefaultConnection.java:51)
        at
rpc.ConnectionOrientedEndpoint.send(ConnectionOrientedEndpoint.java:140)
        at
rpc.ConnectionOrientedEndpoint.connect(ConnectionOrientedEndpoint.java:160)
        at
rpc.ConnectionOrientedEndpoint.bind(ConnectionOrientedEndpoint.java:134)
        at
rpc.ConnectionOrientedEndpoint.call(ConnectionOrientedEndpoint.java:67)
        at rpc.Stub.call(Stub.java:113)
        at jcifs.rpc.LsaRPC.openPolicy(LsaRPC.java:62)
        at jcifs.rpc.LsaRPC.lookupSids(LsaRPC.java:94)
        at jcifs.smb.SmbFile.getSecurity(SmbFile.java:2528)

Using JSwat, I can see that indeed, str is null in that call, but my
lack of knowledge of the library prevents me from figuring out what is
going wrong and where. Any help would be much appreciated!

--
Jake Goulding
Software Engineer
Vivísimo, Inc.

"One of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination
of their C programs."

Reply | Threaded
Open this post in threaded view
|

Re: Null pointer exception in ServerMessageBlock.java

Michael B Allen-4
On Tue, 20 Jun 2006 15:09:13 -0400
Jake Goulding <[hidden email]> wrote:

> At line 212 of ServerMessageBlock.java, I get a Null Pointer Exception,
> and I was hoping someone could help me figure it out.

Looks like the path for the named pipe is null. Can't say for sure why
that is since I don't really use the Lsarpc patch. Just trace up the
call stack and println the path until you find where it's becoming null.

Mike

--
Michael B Allen
PHP Extension for SSO w/ Windows Group Authorization
http://www.ioplex.com/
Reply | Threaded
Open this post in threaded view
|

Re: Null pointer exception in ServerMessageBlock.java

Jake Goulding
Thanks for the tip...

I traced the null String back to line 828 of SmbFile.java:

send( new SmbComNTCreateAndX( unc, flags, access, shareAccess, attrs,
options, null ), response );

unc is null here, so I added a call to getUncPath0() directly before the
if statement. Tracing into the call to getUncPath0(), I see that the if(
in[i] != '/' ) on line 986 is true, causing the function to return null.
Looking at the url given, I see the path is "#@pdc/IPC$/lsarpc". The
host, authority and protocol all seem to be fine.

Any thoughts?

Michael B Allen wrote:

> On Tue, 20 Jun 2006 15:09:13 -0400
> Jake Goulding <[hidden email]> wrote:
>
>  
>> At line 212 of ServerMessageBlock.java, I get a Null Pointer Exception,
>> and I was hoping someone could help me figure it out.
>>    
>
> Looks like the path for the named pipe is null. Can't say for sure why
> that is since I don't really use the Lsarpc patch. Just trace up the
> call stack and println the path until you find where it's becoming null.
>
> Mike
>
>  

--
Jake Goulding
Software Engineer
Vivísimo, Inc.

"One of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination
of their C programs."

Reply | Threaded
Open this post in threaded view
|

Re: Null pointer exception in ServerMessageBlock.java

Michael B Allen-4
On Tue, 20 Jun 2006 17:24:48 -0400
Jake Goulding <[hidden email]> wrote:

> Thanks for the tip...
>
> I traced the null String back to line 828 of SmbFile.java:
>
> send( new SmbComNTCreateAndX( unc, flags, access, shareAccess, attrs,
> options, null ), response );
>
> unc is null here, so I added a call to getUncPath0() directly before the
> if statement. Tracing into the call to getUncPath0(), I see that the if(
> in[i] != '/' ) on line 986 is true, causing the function to return null.
> Looking at the url given, I see the path is "#@pdc/IPC$/lsarpc". The

That's not a valid path. The unc path should look like
\\server\IPC$\lsarpc. The SMB url should look like
smb://server/IPC$/lsarpc.

--
Michael B Allen
PHP Extension for SSO w/ Windows Group Authorization
http://www.ioplex.com/
Reply | Threaded
Open this post in threaded view
|

Re: Null pointer exception in ServerMessageBlock.java

Jake Goulding
I think I have figured this out, and I believe it has to do with the
discrepancy of URL and URI and how things get encoded...

My password has a hash (#) in it. To see what happens, use this test
program:

URL a = new URL("<a href="http://alpha;beta:gamma#@delta/foo/bar">http://alpha;beta:gamma#@delta/foo/bar");
System.out.println("user " + a.getUserInfo());
System.out.println("host " + a.getHost());
System.out.println("path " + a.getPath());
System.out.println("ref " + a.getRef());

The results are:
user alpha;beta:gamma#
host delta
path
ref @delta/foo/bar

What is really strange is the fact that when I run my JCIFS stuff in a
debugger, I do get a path, but it starts with the hash. For the above
url, the path would look like "#@delta/foo/bar".

Obviously, this is not right... the question is where does this need to
be fixed? Do I need to make sure that the user/domain/password are
encoded before passing them off to JCIFS? Does JCIFS need to better
support this? Am I not "allowed" to have a hash in my password?

Thanks!

Michael B Allen wrote:

> On Tue, 20 Jun 2006 17:24:48 -0400
> Jake Goulding <[hidden email]> wrote:
>
>  
>> Thanks for the tip...
>>
>> I traced the null String back to line 828 of SmbFile.java:
>>
>> send( new SmbComNTCreateAndX( unc, flags, access, shareAccess, attrs,
>> options, null ), response );
>>
>> unc is null here, so I added a call to getUncPath0() directly before the
>> if statement. Tracing into the call to getUncPath0(), I see that the if(
>> in[i] != '/' ) on line 986 is true, causing the function to return null.
>> Looking at the url given, I see the path is "#@pdc/IPC$/lsarpc". The
>>    
>
> That's not a valid path. The unc path should look like
> \\server\IPC$\lsarpc. The SMB url should look like
> smb://server/IPC$/lsarpc.
>
>  

--
Jake Goulding
Software Engineer
Vivísimo, Inc.

"One of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination
of their C programs."

Reply | Threaded
Open this post in threaded view
|

Re: Null pointer exception in ServerMessageBlock.java

Ronny Schuetz-2
* Jake Goulding wrote:

Hi,

> Obviously, this is not right... the question is where does this need to
> be fixed? Do I need to make sure that the user/domain/password are
> encoded before passing them off to JCIFS? Does JCIFS need to better
> support this? Am I not "allowed" to have a hash in my password?

Try to URL-encode the username and password before using them to build
the URL. The jakarta commons codec library [1] offers the required
functionality for example.

[1] http://jakarta.apache.org/commons/codec/

Ronny

Reply | Threaded
Open this post in threaded view
|

Re: Re: Null pointer exception in ServerMessageBlock.java

Levi Purvis
Or just use java.net.URLEncoder...

http://java.sun.com/j2se/1.5.0/docs/api/java/net/URLEncoder.html

On 6/21/06, Ronny Schuetz <[hidden email]> wrote:

> * Jake Goulding wrote:
>
> Hi,
>
> > Obviously, this is not right... the question is where does this need to
> > be fixed? Do I need to make sure that the user/domain/password are
> > encoded before passing them off to JCIFS? Does JCIFS need to better
> > support this? Am I not "allowed" to have a hash in my password?
>
> Try to URL-encode the username and password before using them to build
> the URL. The jakarta commons codec library [1] offers the required
> functionality for example.
>
> [1] http://jakarta.apache.org/commons/codec/
>
> Ronny
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Null pointer exception in ServerMessageBlock.java

Michael B Allen-4
In reply to this post by Jake Goulding
Never put your password in the URL. That's a hack for dirty scripts and
developers that just want to test something. Either put your credentials
in a properties file and run the VM like:

  java -Djcifs.properties=beta.prp MyProgram

or better still, create an NPA and pass that to the SmbFile constructor:

  NtlmPasswordAuthentication creds =
      new NtlmPasswordAuthentication("alpha", "beta", "gamma#");
  SmbFile file = new SmbFile(url, creds);

or if you must put your credentials in the URL you must URL encode
any characters reserved for use within URLs. In particular if you
have a '#' or a '%' you need to substitute that with the '%xx'
where 'xx' is the hexadecimal value for that ASCII character like:

   http://alpha;beta:gamma%23@delta/foo/bar

Mike

On Wed, 21 Jun 2006 10:19:28 -0400
Jake Goulding <[hidden email]> wrote:

> I think I have figured this out, and I believe it has to do with the
> discrepancy of URL and URI and how things get encoded...
>
> My password has a hash (#) in it. To see what happens, use this test
> program:
>
> URL a = new URL("<a href="http://alpha;beta:gamma#@delta/foo/bar">http://alpha;beta:gamma#@delta/foo/bar");

--
Michael B Allen
PHP Extension for SSO w/ Windows Group Authorization
http://www.ioplex.com/
Reply | Threaded
Open this post in threaded view
|

Re: Re: Null pointer exception in ServerMessageBlock.java

Jake Goulding
In reply to this post by Levi Purvis
 From the URL JavaDoc:
> The |URLEncoder|
> <http://java.sun.com/j2se/1.5.0/docs/api/java/net/URLEncoder.html> and
> |URLDecoder|
> <http://java.sun.com/j2se/1.5.0/docs/api/java/net/URLDecoder.html>
> classes can also be used, but only for HTML form encoding, which is
> not the same as the encoding scheme defined in RFC2396.
So I think that these classes are for something different than the
encoding needed here... am I wrong?

Levi Purvis wrote:

> Or just use java.net.URLEncoder...
>
> http://java.sun.com/j2se/1.5.0/docs/api/java/net/URLEncoder.html
>
> On 6/21/06, Ronny Schuetz <[hidden email]> wrote:
>> * Jake Goulding wrote:
>>
>> Hi,
>>
>> > Obviously, this is not right... the question is where does this
>> need to
>> > be fixed? Do I need to make sure that the user/domain/password are
>> > encoded before passing them off to JCIFS? Does JCIFS need to better
>> > support this? Am I not "allowed" to have a hash in my password?
>>
>> Try to URL-encode the username and password before using them to build
>> the URL. The jakarta commons codec library [1] offers the required
>> functionality for example.
>>
>> [1] http://jakarta.apache.org/commons/codec/
>>
>> Ronny
>>
>>
>

--
Jake Goulding
Software Engineer
Vivísimo, Inc.

"One of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination
of their C programs."

Reply | Threaded
Open this post in threaded view
|

Re: Null pointer exception in ServerMessageBlock.java

Jake Goulding
In reply to this post by Michael B Allen-4
I agree with you completely. However, I think I was unclear in my prior
email... it is actually Jarapac that does this.

On line 88 of RpcTransport.java:
pipe = new SmbNamedPipe(address, (0x2019f << 16) |
                                SmbNamedPipe.PIPE_TYPE_RDWR |
SmbNamedPipe.PIPE_TYPE_DCE_TRANSACT);

where address is a String field that has the URL in the format of
"<a href="http://alpha;beta:gamma#@delta/foo/bar">http://alpha;beta:gamma#@delta/foo/bar"

My code was just used as an test case to see what happens.

On a side note, Jarapac also has a debug Hexdump... is development of
Jarapac still happening? Is this the right list to send comments about it?

Michael B Allen wrote:

> Never put your password in the URL. That's a hack for dirty scripts and
> developers that just want to test something. Either put your credentials
> in a properties file and run the VM like:
>
>   java -Djcifs.properties=beta.prp MyProgram
>
> or better still, create an NPA and pass that to the SmbFile constructor:
>
>   NtlmPasswordAuthentication creds =
>       new NtlmPasswordAuthentication("alpha", "beta", "gamma#");
>   SmbFile file = new SmbFile(url, creds);
>
> or if you must put your credentials in the URL you must URL encode
> any characters reserved for use within URLs. In particular if you
> have a '#' or a '%' you need to substitute that with the '%xx'
> where 'xx' is the hexadecimal value for that ASCII character like:
>
>    http://alpha;beta:gamma%23@delta/foo/bar
>
> Mike
>
> On Wed, 21 Jun 2006 10:19:28 -0400
> Jake Goulding <[hidden email]> wrote:
>
>  
>> I think I have figured this out, and I believe it has to do with the
>> discrepancy of URL and URI and how things get encoded...
>>
>> My password has a hash (#) in it. To see what happens, use this test
>> program:
>>
>> URL a = new URL("<a href="http://alpha;beta:gamma#@delta/foo/bar">http://alpha;beta:gamma#@delta/foo/bar");
>>    
>
>  

--
Jake Goulding
Software Engineer
Vivísimo, Inc.

"One of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination
of their C programs."

Reply | Threaded
Open this post in threaded view
|

Re: Null pointer exception in ServerMessageBlock.java

Michael B Allen-4
On Wed, 21 Jun 2006 14:19:58 -0400
Jake Goulding <[hidden email]> wrote:

> On a side note, Jarapac also has a debug Hexdump... is development of
> Jarapac still happening? Is this the right list to send comments about it?

Make sure you're NOT using CVS. I horribly broke CVS and shamelessly
have no intention of fixing it. I wish I could just delete the CVS tree
(if anyone knows how to do that please let me know). Download the package.

There is little to no development going on in jCIFS or Jarapac. I no
longer have the time for anything but jCIFS maintainence.

Mike

--
Michael B Allen
PHP Extension for SSO w/ Windows Group Authorization
http://www.ioplex.com/
Reply | Threaded
Open this post in threaded view
|

Re: Null pointer exception in ServerMessageBlock.java

Levi Purvis
In reply to this post by Michael B Allen-4
On 6/21/06, Michael B Allen <[hidden email]> wrote:
> Never put your password in the URL.

Why not?
Reply | Threaded
Open this post in threaded view
|

Re: Null pointer exception in ServerMessageBlock.java

Levi Purvis
In reply to this post by Jake Goulding
URLEncoder will do what you want (I've used it successfully with JCIFS
for encoding username and password in URLs).  The HTML 4 spec points
to RFC1738 (Uniform Resource Locators - URLs) for the encoding used in
the application/x-www-form-urlencoded MIME format.  RFC2396 (Uniform
Resource Identifiers - URIs) "revises and replaces" RFC1738.  The
encoding used in both is essentially the same.

You might be able to just use the URI class and it may do the encoding
for you, not sure.

On 6/21/06, Jake Goulding <[hidden email]> wrote:
>  From the URL JavaDoc:
> > The |URLEncoder|
> > <http://java.sun.com/j2se/1.5.0/docs/api/java/net/URLEncoder.html> and
> > |URLDecoder|
> > <http://java.sun.com/j2se/1.5.0/docs/api/java/net/URLDecoder.html>
> > classes can also be used, but only for HTML form encoding, which is
> > not the same as the encoding scheme defined in RFC2396.
> So I think that these classes are for something different than the
> encoding needed here... am I wrong?
Reply | Threaded
Open this post in threaded view
|

Re: Re: Null pointer exception in ServerMessageBlock.java

David Sprowls-2
In reply to this post by Jake Goulding
Jake,

I am almost certain URLEncoder will not do what you need.  I think I  
ran into problems with it a while back and found that it does not  
encode everything that you would expect.  Get the commons lang  
package from jakarta and use the escapeHtml in the StringEscapeUtils  
class.

Hope that helps.

David

On Jun 21, 2006, at 11:08 AM, Jake Goulding wrote:

> From the URL JavaDoc:
>> The |URLEncoder| <http://java.sun.com/j2se/1.5.0/docs/api/java/net/ 
>> URLEncoder.html> and |URLDecoder| <http://java.sun.com/j2se/1.5.0/ 
>> docs/api/java/net/URLDecoder.html> classes can also be used, but  
>> only for HTML form encoding, which is not the same as the encoding  
>> scheme defined in RFC2396.
> So I think that these classes are for something different than the  
> encoding needed here... am I wrong?
>
> Levi Purvis wrote:
>> Or just use java.net.URLEncoder...
>>
>> http://java.sun.com/j2se/1.5.0/docs/api/java/net/URLEncoder.html
>>
>> On 6/21/06, Ronny Schuetz <[hidden email]> wrote:
>>> * Jake Goulding wrote:
>>>
>>> Hi,
>>>
>>> > Obviously, this is not right... the question is where does this  
>>> need to
>>> > be fixed? Do I need to make sure that the user/domain/password are
>>> > encoded before passing them off to JCIFS? Does JCIFS need to  
>>> better
>>> > support this? Am I not "allowed" to have a hash in my password?
>>>
>>> Try to URL-encode the username and password before using them to  
>>> build
>>> the URL. The jakarta commons codec library [1] offers the required
>>> functionality for example.
>>>
>>> [1] http://jakarta.apache.org/commons/codec/
>>>
>>> Ronny
>>>
>>>
>>
>
> --
> Jake Goulding
> Software Engineer
> Vivísimo, Inc.
>
> "One of the main causes of the fall of the Roman Empire was that,
> lacking zero, they had no way to indicate successful termination
> of their C programs."
>

Reply | Threaded
Open this post in threaded view
|

Re: Null pointer exception in ServerMessageBlock.java

Michael B Allen-4
In reply to this post by Levi Purvis
On Wed, 21 Jun 2006 22:39:18 -0400
"Levi Purvis" <[hidden email]> wrote:

> On 6/21/06, Michael B Allen <[hidden email]> wrote:
> > Never put your password in the URL.
>
> Why not?

Because it's a security hazard.

--
Michael B Allen
PHP Extension for SSO w/ Windows Group Authorization
http://www.ioplex.com/
Reply | Threaded
Open this post in threaded view
|

Re: Null pointer exception in ServerMessageBlock.java

Levi Purvis
> > > Never put your password in the URL.
> >
> > Why not?
>
> Because it's a security hazard.

Could you elaborate, please?  Does it cause the password to be sent as
clear text rather than using NTLM?

I'm asking in the context that the URL w/ credentials is NOT exposed to any UI.
Reply | Threaded
Open this post in threaded view
|

Re: Null pointer exception in ServerMessageBlock.java

Michael B Allen-4
On Thu, 22 Jun 2006 08:35:35 -0400
"Levi Purvis" <[hidden email]> wrote:

> > > > Never put your password in the URL.
> > >
> > > Why not?
> >
> > Because it's a security hazard.
>
> Could you elaborate, please?

URLs have a tendency to be passed around, cached, stored in config files
and are generally promiscuous. For example. it's not inconceivable that
a URL could be printed in a stack trace thereby possibly exposing any
password in it to a user in a browser or terminal window.

For real applications, URLs should never contain passwords. It's only
provided as a convenience to the developer for experimental purposes or
for user's who do not require any guarantee of security.

Mike

--
Michael B Allen
PHP Extension for SSO w/ Windows Group Authorization
http://www.ioplex.com/
Reply | Threaded
Open this post in threaded view
|

Re: Null pointer exception in ServerMessageBlock.java

Edward Costello
I'm curious then. Without specifying the username and password in the URL, is it possible to use JCIFS to authenticate just a particular connection. For Example, we have a single service we connect to using NTLM authentication. We'd like to ensure firstly that the credentials are never sent to any other service that happens to require NTLM authentication. We'd also like to be able to use a different set of credentials for other services that use NTLM authentication.

As far as I could tell from the documentation the only way to set the username and password without putting in in the URL is to use a properties file, system properties or a static configuration object. All of these would result in the credentials being sent to any service that requests NTLM authentication and would prevent us ever using a second set of credentials for a different service.

Cheers
Ed

----- Original Message -----
From: Michael B Allen [hidden email]
To: "Levi Purvis" [hidden email]
Sent: 06/23/2006 7:04:24 AM +1200
Subject: [jcifs] Null pointer exception in ServerMessageBlock.java


On Thu, 22 Jun 2006 08:35:35 -0400
"Levi Purvis" [hidden email] wrote:

  
Never put your password in the URL.
          
Why not?
        
Because it's a security hazard.
      
Could you elaborate, please?
    

URLs have a tendency to be passed around, cached, stored in config files
and are generally promiscuous. For example. it's not inconceivable that
a URL could be printed in a stack trace thereby possibly exposing any
password in it to a user in a browser or terminal window.

For real applications, URLs should never contain passwords. It's only
provided as a convenience to the developer for experimental purposes or
for user's who do not require any guarantee of security.

Mike

  
Reply | Threaded
Open this post in threaded view
|

Re: Null pointer exception in ServerMessageBlock.java

Michael B Allen-4
The general rules for supplying JCIFS credentials are:

1) Create an NtlmPasswordAuthentication (NPA) object and pass that to
   all constructors (e.g. SmbFile).
2) However, if you will only being using one set of credentials you may
   prefer to use properties because it makes the code simpler.
3) You may prefer to put the credentials in a properties file but you
   should take care to set appropriate permissions on the file to protect
   it.
4) If you are only experimenting or your application does not require
   security and you accept that the credentials may be inadvertantly exposed,
   you may choose to place the credentials in the SMB URL for the target
   resource.

Note that ALL of these methods are crude. It would have been better to
integrate with Java's Subject based security model. I started to perform
that work for jCIFS 2 but my situation has since changed and I no longer
have time for new OSS development.

It is unfortunate that so many users have resorted to using method
4. That is perhaps partly my fault as many of the examples do not use
method 1 as they should have.

Mike

On Fri, 23 Jun 2006 08:17:59 +1200
Edward Costello <[hidden email]> wrote:

> I'm curious then. Without specifying the username and password in the
> URL, is it possible to use JCIFS to authenticate just a particular
> connection. For Example, we have a single service we connect to using
> NTLM authentication. We'd like to ensure firstly that the credentials
> are never sent to any other service that happens to require NTLM
> authentication. We'd also like to be able to use a different set of
> credentials for other services that use NTLM authentication.
>
> As far as I could tell from the documentation the only way to set the
> username and password without putting in in the URL is to use a
> properties file, system properties or a static configuration object. All
> of these would result in the credentials being sent to any service that
> requests NTLM authentication and would prevent us ever using a second
> set of credentials for a different service.
>
> Cheers
> Ed
>
> ----- Original Message -----
> *From:* Michael B Allen <[hidden email]>
> *To:* "Levi Purvis" <[hidden email]>
> *CC:* [hidden email]
> *Sent:* 06/23/2006 7:04:24 AM +1200
> *Subject:* [jcifs] Null pointer exception in ServerMessageBlock.java
>
>
> >On Thu, 22 Jun 2006 08:35:35 -0400
> >"Levi Purvis" <[hidden email]> wrote:
> >
> >  
> >
> >>>>>Never put your password in the URL.
> >>>>>          
> >>>>>
> >>>>Why not?
> >>>>        
> >>>>
> >>>Because it's a security hazard.
> >>>      
> >>>
> >>Could you elaborate, please?
> >>    
> >>
> >
> >URLs have a tendency to be passed around, cached, stored in config files
> >and are generally promiscuous. For example. it's not inconceivable that
> >a URL could be printed in a stack trace thereby possibly exposing any
> >password in it to a user in a browser or terminal window.
> >
> >For real applications, URLs should never contain passwords. It's only
> >provided as a convenience to the developer for experimental purposes or
> >for user's who do not require any guarantee of security.
> >
> >Mike
> >
> >  
> >
>


--
Michael B Allen
PHP Extension for SSO w/ Windows Group Authorization
http://www.ioplex.com/
Reply | Threaded
Open this post in threaded view
|

Re: Null pointer exception in ServerMessageBlock.java

Edward Costello
I'd forgotten that this thread was in the context of SMB connections. Is there a way to do something similar to the NtlmPasswordAuthentication for HTTP URL connections authenticated using JCIFS?

Cheers
Ed

----- Original Message -----
From: Michael B Allen [hidden email]
To: Edward Costello [hidden email]
Sent: 06/23/2006 9:47:27 AM +1200
Subject: [jcifs] Null pointer exception in ServerMessageBlock.java


The general rules for supplying JCIFS credentials are:

1) Create an NtlmPasswordAuthentication (NPA) object and pass that to
   all constructors (e.g. SmbFile).
2) However, if you will only being using one set of credentials you may
   prefer to use properties because it makes the code simpler.
3) You may prefer to put the credentials in a properties file but you
   should take care to set appropriate permissions on the file to protect
   it.
4) If you are only experimenting or your application does not require
   security and you accept that the credentials may be inadvertantly exposed,
   you may choose to place the credentials in the SMB URL for the target
   resource.

Note that ALL of these methods are crude. It would have been better to
integrate with Java's Subject based security model. I started to perform
that work for jCIFS 2 but my situation has since changed and I no longer
have time for new OSS development.

It is unfortunate that so many users have resorted to using method
4. That is perhaps partly my fault as many of the examples do not use
method 1 as they should have.

Mike

On Fri, 23 Jun 2006 08:17:59 +1200
Edward Costello [hidden email] wrote:

  
I'm curious then. Without specifying the username and password in the 
URL, is it possible to use JCIFS to authenticate just a particular 
connection. For Example, we have a single service we connect to using 
NTLM authentication. We'd like to ensure firstly that the credentials 
are never sent to any other service that happens to require NTLM 
authentication. We'd also like to be able to use a different set of 
credentials for other services that use NTLM authentication.

As far as I could tell from the documentation the only way to set the 
username and password without putting in in the URL is to use a 
properties file, system properties or a static configuration object. All 
of these would result in the credentials being sent to any service that 
requests NTLM authentication and would prevent us ever using a second 
set of credentials for a different service.

Cheers
Ed

----- Original Message -----
*From:* Michael B Allen [hidden email]
*To:* "Levi Purvis" [hidden email]
*CC:* [hidden email]
*Sent:* 06/23/2006 7:04:24 AM +1200
*Subject:* [jcifs] Null pointer exception in ServerMessageBlock.java


    
On Thu, 22 Jun 2006 08:35:35 -0400
"Levi Purvis" [hidden email] wrote:

 

      
Never put your password in the URL.
         

              
Why not?
       

            
Because it's a security hazard.
     

          
Could you elaborate, please?
   

        
URLs have a tendency to be passed around, cached, stored in config files
and are generally promiscuous. For example. it's not inconceivable that
a URL could be printed in a stack trace thereby possibly exposing any
password in it to a user in a browser or terminal window.

For real applications, URLs should never contain passwords. It's only
provided as a convenience to the developer for experimental purposes or
for user's who do not require any guarantee of security.

Mike

 

      


  
12