Re: InetAddress should utilize networkaddress.cache.ttl for getLocalHost() too

2012-07-31 Thread Deven You 

Hi Michael,

I have submitted a sun bug 7188315. I do not know about CCC request, if 
needed, please conduct me to request it.


Thanks a lot!

On 07/31/2012 05:32 PM, Michael McMahon wrote:

Deven

Is there a bugid for this? We need to submit a CCC request also to 
make the spec change.


Thanks
Michael

On 31/07/12 08:14, Deven You wrote:

Hi Michael,

Thanks for your review, I have updated the patch[1] according to your 
comments.


[1] http://cr.openjdk.java.net/~youdwei/ojdk-527/webrev.03/ 



Thanks a lot!
On 07/25/2012 11:19 PM, Michael McMahon wrote:

On 24/07/12 07:17, Deven You wrote:

Hi Alan and Michael,

I add a java doc[1] for the new networkaddress.cache.localhost.ttl 
property. Please take a look when you have time.




The change looks fine to me. There is a typo in the apidoc in 
InetAddress.
"as as" should be "as an". Might as well correct the same mistake in 
the previous

paragraph also.

Since this is a spec change, it will need a CCC request. Is there a 
bug id for this issue?
Again, I don't know how to set 
cachePolicyPropFallback/negativeCachePolicyPropFallback. Any 
suggestion please tell me.




These are system properties. So, they are normally set on the 
command line with java -Dsun.net.inetaddr.ttl=X 


- Michael.

[1] http://cr.openjdk.java.net/~youdwei/ojdk-527/webrev.01/ 


Thanks a lot!

On 07/12/2012 02:59 PM, Deven You wrote:

Hi Alan and Michael,

Thanks very much for your kind suggestions.

I agree that local host shouldn't follow the default caching 
mechanism because the IP may change frequently. And I also think 
making the cache time configurable is a better solution.


I am willing to make these changes including adding the local host 
caching mechanism into the java doc.


I have gone through the related code for InetAddress.java and 
InetAddressCachePolicy.java. And I think we could add a new 
security property networkaddress.cache.localhost.ttl to achieve 
the goal.


As far as I know, to add networkaddress.cache.localhost.ttl I need 
change jdk/src/share/lib/security/java.security*(include 
java.security, java.security-solaris, java.security-macosx and 
java.security-windows). Please correct me if I have any 
misunderstanding.


Here I have one question need your help:
the static block in InetAddressCachePolicy.java will first try 
to get cachePolicyProp/negativeCachePolicyProp from System 
properties. If one of the cache values is null then the value of 
cachePolicyPropFallback/negativeCachePolicyProp would be got from 
System properties.
   I don't know where we declare these fallback properties so I 
have no idea where I can do the same thing for 
networkaddress.cache.localhost.ttl.


Please take a look.

Thanks a lot!


On 07/11/2012 06:55 PM, Michael McMahon wrote:

On 11/07/12 08:00, Alan Bateman wrote:

On 05/07/2012 07:10, Deven You wrote:

Hi All,

I noticed that InetAddress.getLocalHost() uses cache to improve 
the performance. However the default implementation is caching 
local host within 5 seconds.


From the spec, networkaddress.cache.ttl should be used to 
control the cache behaviour and I think it is a better solution.


For example, if the networkaddress.cache.ttl is set to -1 which 
means always cache the local host then we can avoid unnecessary 
operations on getAddressesFromNameService to improve the 
performance.


I have made a patch for this solution, so anyone would like to 
take a look?


[1] http://cr.openjdk.java.net/~littlee/OJDK-527/webrev.00/ 


Thanks a lot!
--
Best Regards,

Deven
I'm not sure about this one as I suspect it will cause problems 
in DHCP or any environments where the host addresses changes, 
say moving to a different wireless network or waking up a 
machine after hibernation.


-Alan


That's true. We updated the spec for the caching behavior a while 
back, and probably should have included this exception
for the local host. I agree that we shouldn't change the 
behavior. Perhaps, the 5 seconds could be configurable itself,
but I think it should be kept separate from the main caching 
behavior.


- Michael.




--
Best Regards,

Deven



--
Best Regards,

Deven





--
Best Regards,

Deven





--
Best Regards,

Deven

Re: Buffer overflow in C code.

2012-07-31 Thread Chris Hegarty 

[cc'ing net-dev mailing list]

Thanks for reporting this issue.

This looks like 7089443 [1], fixed in jdk8 via 7112670 [2]. Looks like 
icetea needs to sync up, or maybe they are based against the jdk7 repo. 
If so, this could be a good candidate to backport from jdk8 to jdk7 ( 
then I think icetea will get it for free! ).


-Chris.

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7089443
[2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7112670

-Chris.

On 31/07/12 06:07, Robert Święcki wrote:

Hi,

When using Java code compiled with gllibc's fortify source (buffer
overflow detection among others). It crashes:

$ java -jar jar.jar
*** buffer overflow detected ***: java terminated
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7fc56100a007]
/lib/x86_64-linux-gnu/libc.so.6(+0x107f00)[0x7fc561008f00]
/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/libnet.so(Java_java_net_Inet4AddressImpl_getLocalHostName+0x1a0)[0x7fc55d8e4530]
[0x7fc555010d28]
=== Memory map: 
0040-00409000 r-xp  fd:01 2872
   /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java
00608000-00609000 r--p 8000 fd:01 2872
   /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java
00609000-0060a000 rw-p 9000 fd:01 2872
   /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java
01dba000-01ddb000 rw-p  00:00 0  [heap]
cc00-cca7 rw-p  00:00 0
cca7-d9e0 rw-p  00:00 0
d9e0-db2f rw-p  00:00 0
db2f-f5a0 rw-p  00:00 0
f5a0-f6ec rw-p  00:00 0
f6ec-1 rw-p  00:00 0
7fc53800-7fc538021000 rw-p  00:00 0
7fc538021000-7fc53c00 ---p  00:00 0
7fc53c00-7fc53c021000 rw-p  00:00 0
7fc53c021000-7fc54000 ---p  00:00 0
7fc54000-7fc540021000 rw-p  00:00 0
7fc540021000-7fc54400 ---p  00:00 0
7fc54400-7fc5440f5000 rw-p  00:00 0
7fc5440f5000-7fc54800 ---p  00:00 0
7fc54800-7fc548021000 rw-p  00:00 0
7fc548021000-7fc54c00 ---p  00:00 0

IMO, the problem is here

http://icedtea.classpath.org/~vanaltj/webrevs/tl/patch1/jdk/src/solaris/native/java/net/Inet4AddressImpl.c.html
(line 112)

I.e. MAXHOSTNAMELEN is declarative only (a convention), and it is
assumed there that gethostbyaddr-like functions will return strings
which are shorter-equal than 64 (typical value of MAXHOSTNAMELEN).

The machine's FQDN was way over 64 characters, so it crashed. I don't
think it's easily exploitable (requires control over DNS), but it'd be
probably good to fix it.

Re: InetAddress should utilize networkaddress.cache.ttl for getLocalHost() too

2012-07-31 Thread Michael McMahon 

Deven

Is there a bugid for this? We need to submit a CCC request also to make 
the spec change.


Thanks
Michael

On 31/07/12 08:14, Deven You wrote:

Hi Michael,

Thanks for your review, I have updated the patch[1] according to your 
comments.


[1] http://cr.openjdk.java.net/~youdwei/ojdk-527/webrev.03/ 



Thanks a lot!
On 07/25/2012 11:19 PM, Michael McMahon wrote:

On 24/07/12 07:17, Deven You wrote:

Hi Alan and Michael,

I add a java doc[1] for the new networkaddress.cache.localhost.ttl 
property. Please take a look when you have time.




The change looks fine to me. There is a typo in the apidoc in 
InetAddress.
"as as" should be "as an". Might as well correct the same mistake in 
the previous

paragraph also.

Since this is a spec change, it will need a CCC request. Is there a 
bug id for this issue?
Again, I don't know how to set 
cachePolicyPropFallback/negativeCachePolicyPropFallback. Any 
suggestion please tell me.




These are system properties. So, they are normally set on the command 
line with java -Dsun.net.inetaddr.ttl=X 


- Michael.

[1] http://cr.openjdk.java.net/~youdwei/ojdk-527/webrev.01/ 


Thanks a lot!

On 07/12/2012 02:59 PM, Deven You wrote:

Hi Alan and Michael,

Thanks very much for your kind suggestions.

I agree that local host shouldn't follow the default caching 
mechanism because the IP may change frequently. And I also think 
making the cache time configurable is a better solution.


I am willing to make these changes including adding the local host 
caching mechanism into the java doc.


I have gone through the related code for InetAddress.java and 
InetAddressCachePolicy.java. And I think we could add a new 
security property networkaddress.cache.localhost.ttl to achieve the 
goal.


As far as I know, to add networkaddress.cache.localhost.ttl I need 
change jdk/src/share/lib/security/java.security*(include 
java.security, java.security-solaris, java.security-macosx and 
java.security-windows). Please correct me if I have any 
misunderstanding.


Here I have one question need your help:
the static block in InetAddressCachePolicy.java will first try 
to get cachePolicyProp/negativeCachePolicyProp from System 
properties. If one of the cache values is null then the value of 
cachePolicyPropFallback/negativeCachePolicyProp would be got from 
System properties.
   I don't know where we declare these fallback properties so I 
have no idea where I can do the same thing for 
networkaddress.cache.localhost.ttl.


Please take a look.

Thanks a lot!


On 07/11/2012 06:55 PM, Michael McMahon wrote:

On 11/07/12 08:00, Alan Bateman wrote:

On 05/07/2012 07:10, Deven You wrote:

Hi All,

I noticed that InetAddress.getLocalHost() uses cache to improve 
the performance. However the default implementation is caching 
local host within 5 seconds.


From the spec, networkaddress.cache.ttl should be used to 
control the cache behaviour and I think it is a better solution.


For example, if the networkaddress.cache.ttl is set to -1 which 
means always cache the local host then we can avoid unnecessary 
operations on getAddressesFromNameService to improve the 
performance.


I have made a patch for this solution, so anyone would like to 
take a look?


[1] http://cr.openjdk.java.net/~littlee/OJDK-527/webrev.00/ 


Thanks a lot!
--
Best Regards,

Deven
I'm not sure about this one as I suspect it will cause problems 
in DHCP or any environments where the host addresses changes, say 
moving to a different wireless network or waking up a machine 
after hibernation.


-Alan


That's true. We updated the spec for the caching behavior a while 
back, and probably should have included this exception
for the local host. I agree that we shouldn't change the behavior. 
Perhaps, the 5 seconds could be configurable itself,

but I think it should be kept separate from the main caching behavior.

- Michael.




--
Best Regards,

Deven



--
Best Regards,

Deven





--
Best Regards,

Deven

Re: InetAddress should utilize networkaddress.cache.ttl for getLocalHost() too

2012-07-31 Thread Deven You 

Hi Michael,

Thanks for your review, I have updated the patch[1] according to your 
comments.


[1] http://cr.openjdk.java.net/~youdwei/ojdk-527/webrev.03/ 



Thanks a lot!
On 07/25/2012 11:19 PM, Michael McMahon wrote:

On 24/07/12 07:17, Deven You wrote:

Hi Alan and Michael,

I add a java doc[1] for the new networkaddress.cache.localhost.ttl 
property. Please take a look when you have time.




The change looks fine to me. There is a typo in the apidoc in InetAddress.
"as as" should be "as an". Might as well correct the same mistake in 
the previous

paragraph also.

Since this is a spec change, it will need a CCC request. Is there a 
bug id for this issue?
Again, I don't know how to set 
cachePolicyPropFallback/negativeCachePolicyPropFallback. Any 
suggestion please tell me.




These are system properties. So, they are normally set on the command 
line with java -Dsun.net.inetaddr.ttl=X 


- Michael.

[1] http://cr.openjdk.java.net/~youdwei/ojdk-527/webrev.01/ 


Thanks a lot!

On 07/12/2012 02:59 PM, Deven You wrote:

Hi Alan and Michael,

Thanks very much for your kind suggestions.

I agree that local host shouldn't follow the default caching 
mechanism because the IP may change frequently. And I also think 
making the cache time configurable is a better solution.


I am willing to make these changes including adding the local host 
caching mechanism into the java doc.


I have gone through the related code for InetAddress.java and 
InetAddressCachePolicy.java. And I think we could add a new security 
property networkaddress.cache.localhost.ttl to achieve the goal.


As far as I know, to add networkaddress.cache.localhost.ttl I need 
change jdk/src/share/lib/security/java.security*(include 
java.security, java.security-solaris, java.security-macosx and 
java.security-windows). Please correct me if I have any 
misunderstanding.


Here I have one question need your help:
the static block in InetAddressCachePolicy.java will first try 
to get cachePolicyProp/negativeCachePolicyProp from System 
properties. If one of the cache values is null then the value of 
cachePolicyPropFallback/negativeCachePolicyProp would be got from 
System properties.
   I don't know where we declare these fallback properties so I have 
no idea where I can do the same thing for 
networkaddress.cache.localhost.ttl.


Please take a look.

Thanks a lot!


On 07/11/2012 06:55 PM, Michael McMahon wrote:

On 11/07/12 08:00, Alan Bateman wrote:

On 05/07/2012 07:10, Deven You wrote:

Hi All,

I noticed that InetAddress.getLocalHost() uses cache to improve 
the performance. However the default implementation is caching 
local host within 5 seconds.


From the spec, networkaddress.cache.ttl should be used to control 
the cache behaviour and I think it is a better solution.


For example, if the networkaddress.cache.ttl is set to -1 which 
means always cache the local host then we can avoid unnecessary 
operations on getAddressesFromNameService to improve the performance.


I have made a patch for this solution, so anyone would like to 
take a look?


[1] http://cr.openjdk.java.net/~littlee/OJDK-527/webrev.00/ 


Thanks a lot!
--
Best Regards,

Deven
I'm not sure about this one as I suspect it will cause problems in 
DHCP or any environments where the host addresses changes, say 
moving to a different wireless network or waking up a machine 
after hibernation.


-Alan


That's true. We updated the spec for the caching behavior a while 
back, and probably should have included this exception
for the local host. I agree that we shouldn't change the behavior. 
Perhaps, the 5 seconds could be configurable itself,

but I think it should be kept separate from the main caching behavior.

- Michael.




--
Best Regards,

Deven



--
Best Regards,

Deven





--
Best Regards,

Deven