Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #27293 > unrolled thread

New Java JDK released

Back to article view | Back to comp.lang.java.programmer

Contents

  New Java JDK released Roedy Green <see_website@mindprod.com.invalid> - 2014-01-14 21:45 -0800
    Re: New Java JDK released "Qu0ll" <Qu0llSixFour@gmail.com> - 2014-01-15 18:30 +1100
      Re: New Java JDK released Roedy Green <see_website@mindprod.com.invalid> - 2014-01-15 03:37 -0800
        Re: New Java JDK released Arne Vajhøj <arne@vajhoej.dk> - 2014-01-15 22:24 -0500
          Re: New Java JDK released Joerg Meier <joergmmeier@arcor.de> - 2014-01-16 12:41 +0100
    Re: New Java JDK released Silvio <silvio@internet.com> - 2014-01-15 15:43 +0100
      Re: New Java JDK released Donkey Hottie <donkey@fredriksson.dy.fi> - 2014-01-15 21:28 +0200
        Re: New Java JDK released markspace <markspace@nospam.nospam> - 2014-01-15 11:46 -0800
          Re: New Java JDK released Silvio <silvio@internet.com> - 2014-01-15 23:34 +0100
            Re: New Java JDK released markspace <markspace@nospam.nospam> - 2014-01-15 14:41 -0800
              Re: New Java JDK released Silvio <silvio@internet.com> - 2014-01-16 01:14 +0100
                Re: New Java JDK released Arne Vajhøj <arne@vajhoej.dk> - 2014-01-15 22:18 -0500
                  Re: New Java JDK released Silvio <silvio@internet.com> - 2014-01-16 09:08 +0100
                    Re: ephemeral ports [was: New Java JDK released] Wayne <nospam@all.invalid> - 2014-01-16 04:21 -0500
                      Re: ephemeral ports [was: New Java JDK released] Silvio <silvio@internet.com> - 2014-01-16 10:35 +0100
                      Re: ephemeral ports [was: New Java JDK released] lipska the kat <lipskathekat@example.com> - 2014-01-16 09:42 +0000
                  Re: New Java JDK released Knute Johnson <eternal@knutejohnson.com> - 2014-01-16 09:29 -0800
            Re: New Java JDK released Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2014-01-15 18:46 -0800
              Re: New Java JDK released Silvio <silvio@internet.com> - 2014-01-16 08:50 +0100
                Re: New Java JDK released Joerg Meier <joergmmeier@arcor.de> - 2014-01-16 12:45 +0100
                  Re: New Java JDK released Silvio <silvio@internet.com> - 2014-01-16 13:05 +0100
      Re: New Java JDK released Roedy Green <see_website@mindprod.com.invalid> - 2014-01-15 16:14 -0800
        Re: New Java JDK released Silvio <silvio@internet.com> - 2014-01-16 01:19 +0100
          Re: New Java JDK released Roedy Green <see_website@mindprod.com.invalid> - 2014-01-17 01:47 -0800
    Re: New Java JDK released Michal Kleczek <michal_wytnijto@kleczek.org> - 2014-01-16 11:37 +0100

Page 1 of 2  [1] 2  Next page →

#27293 — New Java JDK released

Java 1.7.9_51 was released today.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Unlike many machines, computers require no water once they are
manufactured.

[toc] | [next] | [standalone]

#27294

"Roedy Green"  wrote in message 
news:i28cd993k62hvs9cmk2fiknrfh366rm1gr@4ax.com...

> Java 1.7.9_51 was released today.

1.7.0_51

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour@gmail.com
[Replace the "SixFour" with numbers to email me] 

[toc] | [prev] | [next] | [standalone]

#27295

On Wed, 15 Jan 2014 18:30:11 +1100, "Qu0ll" <Qu0llSixFour@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>
>> Java 1.7.9_51 was released today.
>
>1.7.0_51

oops.  Sorry about that. For hints on installing see
http://mindprod.com/jgloss/jdk.html
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Unlike many machines, computers require no water once they are
manufactured.

[toc] | [prev] | [next] | [standalone]

#27306

On 1/15/2014 6:37 AM, Roedy Green wrote:
> On Wed, 15 Jan 2014 18:30:11 +1100, "Qu0ll" <Qu0llSixFour@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
>>> Java 1.7.9_51 was released today.
>>
>> 1.7.0_51
>
> oops.  Sorry about that. For hints on installing see
> http://mindprod.com/jgloss/jdk.html

Interesting page.

I wonder who can find the most errors on that page.

Arne

[toc] | [prev] | [next] | [standalone]

#27314

On Wed, 15 Jan 2014 22:24:49 -0500, Arne Vajhøj wrote:

> On 1/15/2014 6:37 AM, Roedy Green wrote:
>> On Wed, 15 Jan 2014 18:30:11 +1100, "Qu0ll" <Qu0llSixFour@gmail.com>
>> wrote, quoted or indirectly quoted someone who said :
>>>> Java 1.7.9_51 was released today.
>>> 1.7.0_51
>> oops.  Sorry about that. For hints on installing see
>> http://mindprod.com/jgloss/jdk.html
> Interesting page.

> I wonder who can find the most errors on that page.

Considering he still hasn't fixed the multiple Windows issues that were
pointed out to him here over a year ago, it seems like listing them would
be a waste of everyones time.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#27296

On 01/15/2014 06:45 AM, Roedy Green wrote:
> Java 1.7.9_51 was released today.
>

Did anyone try it to see what the impact of the restriction for server 
sockets to the "ephemeral port range" is? I am running heaps of servlet 
container processes on a cluster of Linux servers and this change seems 
to prohibit listening on sockets in the range 1024-<way high>.

Why on earth did they do that?

Silvio

[toc] | [prev] | [next] | [standalone]

#27297

15.01.2014 16:43, Silvio kirjoitti:
> On 01/15/2014 06:45 AM, Roedy Green wrote:
>> Java 1.7.9_51 was released today.
>>
> 
> Did anyone try it to see what the impact of the restriction for server
> sockets to the "ephemeral port range" is? I am running heaps of servlet
> container processes on a cluster of Linux servers and this change seems
> to prohibit listening on sockets in the range 1024-<way high>.
> 
> Why on earth did they do that?
> 
> Silvio
> 

If that is true, it breaks most if not all application servers out
there. They are normally run as non root, and listening high ports.

-- 

Q:	How many existentialists does it take to screw in a light bulb?
A:	Two.  One to screw it in and one to observe how the light bulb
	itself symbolizes a single incandescent beacon of subjective
	reality in a netherworld of endless absurdity reaching out toward a
	maudlin cosmos of nothingness.

[toc] | [prev] | [next] | [standalone]

#27298

Before any rumors get started, here's what the release notes actually say:

"The default socket permissions assigned to all code including untrusted 
code have been changed in this release. Previously, all code was able to 
bind any socket type to any port number greater than or equal to 1024. 
It is still possible to bind sockets to the ephemeral port range on each 
system...

"Applications using datagram sockets or server tcp sockets (and a 
security manager) may encounter security exceptions where none were seen 
before. If this occurs, users should review whether the port number 
being requested is expected, and if this is the case, a socket 
permission grant can be added to the local security policy, to resolve 
the issue."


So you might have to change the default configuration IF you are also 
using the security manager, but that's it.

http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html



On 1/15/2014 11:28 AM, Donkey Hottie wrote:
> 15.01.2014 16:43, Silvio kirjoitti:
>> On 01/15/2014 06:45 AM, Roedy Green wrote:
>>> Java 1.7.9_51 was released today.
>>>
>>
>> Did anyone try it to see what the impact of the restriction for server
>> sockets to the "ephemeral port range" is? I am running heaps of servlet
>> container processes on a cluster of Linux servers and this change seems
>> to prohibit listening on sockets in the range 1024-<way high>.
>>
>> Why on earth did they do that?
>>
>> Silvio
>>
>
> If that is true, it breaks most if not all application servers out
> there. They are normally run as non root, and listening high ports.
>

[toc] | [prev] | [next] | [standalone]

#27299

On 01/15/2014 08:46 PM, markspace wrote:
> Before any rumors get started, here's what the release notes actually say:
>
> "The default socket permissions assigned to all code including untrusted
> code have been changed in this release. Previously, all code was able to
> bind any socket type to any port number greater than or equal to 1024.
> It is still possible to bind sockets to the ephemeral port range on each
> system...
>
> "Applications using datagram sockets or server tcp sockets (and a
> security manager) may encounter security exceptions where none were seen
> before. If this occurs, users should review whether the port number
> being requested is expected, and if this is the case, a socket
> permission grant can be added to the local security policy, to resolve
> the issue."
>
>
> So you might have to change the default configuration IF you are also
> using the security manager, but that's it.
>
> http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html
>
>
>
> On 1/15/2014 11:28 AM, Donkey Hottie wrote:
>> 15.01.2014 16:43, Silvio kirjoitti:
>>> On 01/15/2014 06:45 AM, Roedy Green wrote:
>>>> Java 1.7.9_51 was released today.
>>>>
>>>
>>> Did anyone try it to see what the impact of the restriction for server
>>> sockets to the "ephemeral port range" is? I am running heaps of servlet
>>> container processes on a cluster of Linux servers and this change seems
>>> to prohibit listening on sockets in the range 1024-<way high>.
>>>
>>> Why on earth did they do that?
>>>
>>> Silvio
>>>
>>
>> If that is true, it breaks most if not all application servers out
>> there. They are normally run as non root, and listening high ports.
>>
>
>

Correct me if I am wrong but I read this as if my servers can no longer 
listen on ports in the 1024-4000 range like they do now unless I dive 
into some Java policy descriptor that I have never looked at before in 
about 15 years of Java server side programming or manually change the 
ephemeral port range on the server.

Sounds alarming to me. That is quite a disruption. I routinely have to 
deploy servers onto cloud servers without having root access. And what 
if I (or god help; my customer) do a Java version upgrade: do I have to 
modify that policy thingy again?

Until someone explains to me why this change makes sense I call it a 
stupid move. Reminds me of the Host header change they made to the URL 
class somewhere around 1.7.0_26. That broke quite some reverse HTTP 
proxy code that had been running for over ten years.

Silvio

[toc] | [prev] | [next] | [standalone]

#27300

On 1/15/2014 2:34 PM, Silvio wrote:

> Until someone explains to me why this change makes sense I call it a

I did explain it.  Here's my question: did you try this on a test server 
to see if it's actually a problem for you, or are you just making stuff 
up when you say it's a problem?

[toc] | [prev] | [next] | [standalone]

#27301

On 01/15/2014 11:41 PM, markspace wrote:
> On 1/15/2014 2:34 PM, Silvio wrote:
>
>> Until someone explains to me why this change makes sense I call it a
>
> I did explain it.  Here's my question: did you try this on a test server
> to see if it's actually a problem for you, or are you just making stuff
> up when you say it's a problem?
>
>

No, I did not try this because the Linux servers I have available are 
not rolling release ones so I can not yet upgrade my Java. Additionally, 
I am not able to test on all platforms I currently deploy to. That is 
why I was asking if someone else did experiment, I welcome any 
additional info.

I read the release notes and am worried that I may run into problems in 
the near future, perhaps when one of my users does a system upgrade like 
they have done so often. You make it seem like I am trying to cause a 
panic but I just wanted to achieve two things: find out if someone could 
either confirm or falsify my worries and make other people aware of the 
policy change since I know by experience that many upgrade their Javas 
without reading the release notes.

I still hope that I am wrong but if that is the fact then the release 
note is at least vague. If not (and I think I can read, hence my 
worries) then I wonder why such possibly disrupting changes are made in 
minor releases with only a footnote in the release notes.

And you did not explain anything. You just copied the release note I 
already read. If the change was made for security reasons (what else 
could there be) then I would like some explanation about the security 
breach that is closed with it.

[toc] | [prev] | [next] | [standalone]

#27305

On 1/15/2014 7:14 PM, Silvio wrote:
> On 01/15/2014 11:41 PM, markspace wrote:
>> On 1/15/2014 2:34 PM, Silvio wrote:
>>
>>> Until someone explains to me why this change makes sense I call it a
>>
>> I did explain it.  Here's my question: did you try this on a test server
>> to see if it's actually a problem for you, or are you just making stuff
>> up when you say it's a problem?
>
> No, I did not try this because the Linux servers I have available are
> not rolling release ones so I can not yet upgrade my Java. Additionally,
> I am not able to test on all platforms I currently deploy to. That is
> why I was asking if someone else did experiment, I welcome any
> additional info.

Are there any reason to believe that this change is platform specific?

If not then testing on one platform (like you development platform)
should give a decent indication.

And you would test on your deployment platforms when they
upgrade some day anyway.

> I read the release notes and am worried that I may run into problems in
> the near future, perhaps when one of my users does a system upgrade like
> they have done so often. You make it seem like I am trying to cause a
> panic but I just wanted to achieve two things: find out if someone could
> either confirm or falsify my worries and make other people aware of the
> policy change since I know by experience that many upgrade their Javas
> without reading the release notes.
>
> I still hope that I am wrong but if that is the fact then the release
> note is at least vague. If not (and I think I can read, hence my
> worries) then I wonder why such possibly disrupting changes are made in
> minor releases with only a footnote in the release notes.
>
> And you did not explain anything. You just copied the release note I
> already read. If the change was made for security reasons (what else
> could there be) then I would like some explanation about the security
> breach that is closed with it.

I can not see what is vague.

I read Marks post and it took less time to develop examples
showing the topic under discussion than to write this post.

import java.io.IOException;
import java.net.ServerSocket;

public class SS {
	public static void main(String[] args) throws IOException {
		new ServerSocket(2000);
	}
}

work on both _45 and _51.

import java.io.IOException;
import java.net.ServerSocket;
import java.rmi.RMISecurityManager;

public class SMSS {
	public static void main(String[] args) throws IOException {
		System.setSecurityManager(new RMISecurityManager());
		new ServerSocket(2000);
	}
}

works on _45 and throws an AccessControlException on _51.

Lots of people update Java without reading release notes. But
very few Java users actually uses a security manager. And if they
do then they will or at least should know how to read documentation.

The reason behind the change does not impact how it works or
what other changes may be necessary for the few using a security
manager.

Arne

[toc] | [prev] | [next] | [standalone]

#27308

On 01/16/2014 04:18 AM, Arne Vajhøj wrote:
>
> Are there any reason to believe that this change is platform specific?
>

Yes. The so called "ephemeral port range" differs per Linux 
version/distro for example.

> If not then testing on one platform (like you development platform)
> should give a decent indication.

I could and I will once I have the time. But I may be beaten to it by 
one of my users.

>
> And you would test on your deployment platforms when they
> upgrade some day anyway.

No I wouldn't. I have continuous access to about 20% of my current 
deployment platforms. Upgrading of a number of them happens outside of 
my control. In fact, some older installations run under a SLA that 
explicitly allows minor Java version upgrades (explicitly negotiated by 
the customers).

>
>
> I can not see what is vague.
>

They are not very explicit in stating that server sockets without the 
use of a SecurityManager are not affected. They only mention the SM 
inside brackets.

> I read Marks post and it took less time to develop examples
> showing the topic under discussion than to write this post.
>
> import java.io.IOException;
> import java.net.ServerSocket;
>
> public class SS {
>      public static void main(String[] args) throws IOException {
>          new ServerSocket(2000);
>      }
> }
>
> work on both _45 and _51.
>
> import java.io.IOException;
> import java.net.ServerSocket;
> import java.rmi.RMISecurityManager;
>
> public class SMSS {
>      public static void main(String[] args) throws IOException {
>          System.setSecurityManager(new RMISecurityManager());
>          new ServerSocket(2000);
>      }
> }
>
> works on _45 and throws an AccessControlException on _51.
>

Well, that confirms what Mark said and that is a good thing (unless you 
are on Windows XP for example since 2000 is ephemeral there). 
Unfortunately I do not create the server sockets myself but use about 
half a dozen libraries that create in process embedded servers (among 
which Jetty and H2Database) so I am not sure yet what these libraries do 
under what circumstances.

[toc] | [prev] | [next] | [standalone]

#27310 — Re: ephemeral ports [was: New Java JDK released]

On 1/16/2014 3:08 AM, Silvio wrote:
> On 01/16/2014 04:18 AM, Arne Vajhøj wrote:
>>
>> Are there any reason to believe that this change is platform specific?
>>
> 
> Yes. The so called "ephemeral port range" differs per Linux version/distro for example.

I'm not sure about that.  "ephemeral port" is not a defined term.  I assume
they mean the private (a.k.a. "dynamic") port range.  This is defined in an
RFC and by the IANA
(<https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml>):

<quote>
...
Port numbers are assigned in various ways, based on three ranges: System
Ports (0-1023), User Ports (1024-49151), and the Dynamic and/or Private
Ports (49152-65535); the difference uses of these ranges is described in
[RFC6335].
...
</quote>

-- 
Wayne

[toc] | [prev] | [next] | [standalone]

#27311 — Re: ephemeral ports [was: New Java JDK released]

On 01/16/2014 10:21 AM, Wayne wrote:
> On 1/16/2014 3:08 AM, Silvio wrote:
>> On 01/16/2014 04:18 AM, Arne Vajhøj wrote:
>>>
>>> Are there any reason to believe that this change is platform specific?
>>>
>>
>> Yes. The so called "ephemeral port range" differs per Linux version/distro for example.
>
> I'm not sure about that.  "ephemeral port" is not a defined term.  I assume
> they mean the private (a.k.a. "dynamic") port range.  This is defined in an
> RFC and by the IANA
> (<https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml>):
>
> <quote>
> ...
> Port numbers are assigned in various ways, based on three ranges: System
> Ports (0-1023), User Ports (1024-49151), and the Dynamic and/or Private
> Ports (49152-65535); the difference uses of these ranges is described in
> [RFC6335].
> ...
> </quote>
>

I did not introduce the term, it was used in the release notes and 
Google reveals it is not an uncommon term. The IANA does set some 
standard but Googling "ephemeral port range" revealed that Windows up to 
XP, BSD and older Linux kernels use different ranges, sometimes even 
dependant of the available memory (mentioned only for Linux). The Linux 
machines I tried all seem to use the range 32768-61000.

[toc] | [prev] | [next] | [standalone]

#27312 — Re: ephemeral ports [was: New Java JDK released]

On 16/01/14 09:21, Wayne wrote:
> On 1/16/2014 3:08 AM, Silvio wrote:
>> On 01/16/2014 04:18 AM, Arne Vajhøj wrote:
>>>
>>> Are there any reason to believe that this change is platform specific?
>>>
>>
>> Yes. The so called "ephemeral port range" differs per Linux version/distro for example.
>
> I'm not sure about that.  "ephemeral port" is not a defined term.

Well possibly not but it is widely used and understood
Also, on Linux it is possible to modify the range of ephemeral ports.

http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html#Linux

On this kernel 3.2.0-23 box

$ cat /proc/sys/net/ipv4/ip_local_port_range
32768	61000

$ sudo echo "1024 4999" > /proc/sys/net/ipv4/ip_local_port_range

changes the range

IANA doesn't 'define' an ephemeral port range IIRC, rather it is a 
'suggestion'


-- 
Lipska the Kat©: Troll hunter, sandbox destroyer,
treacherous feline and farscape dreamer of Aeryn Sun
GNU/Linux user #560883 - http://www.linuxcounter.net

[toc] | [prev] | [next] | [standalone]

#27321

On 1/15/2014 19:18, Arne Vajhøj wrote:
> import java.io.IOException;
> import java.net.ServerSocket;
> import java.rmi.RMISecurityManager;
>
> public class SMSS {
>      public static void main(String[] args) throws IOException {
>          System.setSecurityManager(new RMISecurityManager());
>          new ServerSocket(2000);
>      }
> }

I modified your code a little to use a plain SecurityManager and tested 
it on my Windows 8.1.  The ports 49151 and below throw the exception but 
not above that.

Some fellow over on the Ubuntu users list just had his stock quote 
program upchuck when he updated to _51 on U.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#27304

In article <52d70cf7$0$2891$e4fe514c@news2.news.xs4all.nl>,
 Silvio <silvio@internet.com> wrote:

> On 01/15/2014 08:46 PM, markspace wrote:
> > Before any rumors get started, here's what the release notes actually say:
> >
> > "The default socket permissions assigned to all code including untrusted
> > code have been changed in this release. Previously, all code was able to
> > bind any socket type to any port number greater than or equal to 1024.
> > It is still possible to bind sockets to the ephemeral port range on each
> > system...
> >
> > "Applications using datagram sockets or server tcp sockets (and a
> > security manager) may encounter security exceptions where none were seen
> > before. If this occurs, users should review whether the port number
> > being requested is expected, and if this is the case, a socket
> > permission grant can be added to the local security policy, to resolve
> > the issue."
> >
> >
> > So you might have to change the default configuration IF you are also
> > using the security manager, but that's it.
> >
> > http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html
> >
> >
> >
> > On 1/15/2014 11:28 AM, Donkey Hottie wrote:
> >> 15.01.2014 16:43, Silvio kirjoitti:
> >>> On 01/15/2014 06:45 AM, Roedy Green wrote:
> >>>> Java 1.7.9_51 was released today.
> >>>>
> >>>
> >>> Did anyone try it to see what the impact of the restriction for server
> >>> sockets to the "ephemeral port range" is? I am running heaps of servlet
> >>> container processes on a cluster of Linux servers and this change seems
> >>> to prohibit listening on sockets in the range 1024-<way high>.
> >>>
> >>> Why on earth did they do that?
> >>>
> >>> Silvio
> >>>
> >>
> >> If that is true, it breaks most if not all application servers out
> >> there. They are normally run as non root, and listening high ports.
> >>
> >
> >
> 
> Correct me if I am wrong but I read this as if my servers can no longer 
> listen on ports in the 1024-4000 range like they do now unless I dive 
> into some Java policy descriptor that I have never looked at before in 
> about 15 years of Java server side programming or manually change the 
> ephemeral port range on the server.
> 
> Sounds alarming to me. That is quite a disruption. I routinely have to 
> deploy servers onto cloud servers without having root access. And what 
> if I (or god help; my customer) do a Java version upgrade: do I have to 
> modify that policy thingy again?
> 
> Until someone explains to me why this change makes sense I call it a 
> stupid move. Reminds me of the Host header change they made to the URL 
> class somewhere around 1.7.0_26. That broke quite some reverse HTTP 
> proxy code that had been running for over ten years.
> 
> Silvio

You're clearly not using the Security Manager if you haven't touched 
security configurations.  It's a whitelist that needs to be maintained 
as features are added.  This change wouldn't impact you.

[toc] | [prev] | [next] | [standalone]

#27307

On 01/16/2014 03:46 AM, Kevin McMurtrie wrote:
> In article <52d70cf7$0$2891$e4fe514c@news2.news.xs4all.nl>,
>   Silvio <silvio@internet.com> wrote:
>
>> On 01/15/2014 08:46 PM, markspace wrote:
>>> Before any rumors get started, here's what the release notes actually say:
>>>
>>> "The default socket permissions assigned to all code including untrusted
>>> code have been changed in this release. Previously, all code was able to
>>> bind any socket type to any port number greater than or equal to 1024.
>>> It is still possible to bind sockets to the ephemeral port range on each
>>> system...
>>>
>>> "Applications using datagram sockets or server tcp sockets (and a
>>> security manager) may encounter security exceptions where none were seen
>>> before. If this occurs, users should review whether the port number
>>> being requested is expected, and if this is the case, a socket
>>> permission grant can be added to the local security policy, to resolve
>>> the issue."
>>>
>>>
>>> So you might have to change the default configuration IF you are also
>>> using the security manager, but that's it.
>>>
>>> http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html
>>>
>>>
>>>
>>> On 1/15/2014 11:28 AM, Donkey Hottie wrote:
>>>> 15.01.2014 16:43, Silvio kirjoitti:
>>>>> On 01/15/2014 06:45 AM, Roedy Green wrote:
>>>>>> Java 1.7.9_51 was released today.
>>>>>>
>>>>>
>>>>> Did anyone try it to see what the impact of the restriction for server
>>>>> sockets to the "ephemeral port range" is? I am running heaps of servlet
>>>>> container processes on a cluster of Linux servers and this change seems
>>>>> to prohibit listening on sockets in the range 1024-<way high>.
>>>>>
>>>>> Why on earth did they do that?
>>>>>
>>>>> Silvio
>>>>>
>>>>
>>>> If that is true, it breaks most if not all application servers out
>>>> there. They are normally run as non root, and listening high ports.
>>>>
>>>
>>>
>>
>> Correct me if I am wrong but I read this as if my servers can no longer
>> listen on ports in the 1024-4000 range like they do now unless I dive
>> into some Java policy descriptor that I have never looked at before in
>> about 15 years of Java server side programming or manually change the
>> ephemeral port range on the server.
>>
>> Sounds alarming to me. That is quite a disruption. I routinely have to
>> deploy servers onto cloud servers without having root access. And what
>> if I (or god help; my customer) do a Java version upgrade: do I have to
>> modify that policy thingy again?
>>
>> Until someone explains to me why this change makes sense I call it a
>> stupid move. Reminds me of the Host header change they made to the URL
>> class somewhere around 1.7.0_26. That broke quite some reverse HTTP
>> proxy code that had been running for over ten years.
>>
>> Silvio
>
> You're clearly not using the Security Manager if you haven't touched
> security configurations.  It's a whitelist that needs to be maintained
> as features are added.  This change wouldn't impact you.
>

No, I am not using the Security Manager. My code runs on (mostly 
dedicated) servers and I have never needed it.

Why does this change not impact me?

Cheers,

Silvio

[toc] | [prev] | [next] | [standalone]

#27315

On Thu, 16 Jan 2014 08:50:22 +0100, Silvio wrote:

> No, I am not using the Security Manager. My code runs on (mostly 
> dedicated) servers and I have never needed it.

> Why does this change not impact me?

Why would a change that explicitly says that it's a permissions change that
affects Sockets used together with a SecurityManager affect something
without a SecurityManager ? Are you also worried it will impact your file
reading, or array initializing ?

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web