Re: The D Programming Language
Niklas Matthies wrote:
{ please move on to discussing C++ or choose a different venue.
thank you. -mod }
I'll try. I do think that comparing the memory and object
models of different languages is acceptable (provided one of the
languages is C++, of course).
On 2006-12-16 18:06, James Kanze wrote:
{ I'm approving this because it's part of an ongoing discussion, but
please don't start a thread about Java security in clc++m. -mod/aps }
Right.
Niklas Matthies wrote:
On 2006-12-15 13:23, James Kanze wrote:
:
In the case of Java, the problem concerning literals may be the
most shocking, externally, but the fact that you can modify a
String after having passed it to another subsystem is far more
serious, since it undermines many of Java's security measures.
No, it doesn't, because a security-conscious application will
run under a SecurityManager that will prevent such accesses
(the setAccessible() call will fail).
You seem to have missed the point. The SecurityManager sees a
valid URL (filename, or whatever). It's only after the
SecurityManager has approved the operation that the value
changes.
I'm not sure who's missing the point here. The value won't be able to
change unless the SecurityManager allows the application to change the
value. The SecurityManager, or, more generally, the security policy is
global for the JVM, and can be set when starting up the JVM, such that
the application has no way whatsoever to bypass it.
You're missing the point entirely. And it's not relevant to
just security. In C++, a string literal has the value that
appears in the code. Period. With many compilers, it's in
write protected memory, so it is physically impossible to change
it. IMHO, this is essential not only for security reasons, but
in order to be able to understand the code. In C++, if I need a
string whose value cannot change after I receive it, I can use
pass by value; from that point on, I operate on a copy of the
original string, and the providing code cannot even see the
string I'm using. This is essential to security, and can also
have an effect on readability. Java's doesn't have pass by
value, and counts on immutability to achieve the same effect.
So, whether the value of string literals and private data can change
in Java is a matter of configuration.
You can't configure Java so that it is single threaded, nor that
it use deep copy. Which means that there is no way to prevent
the modification of the String data using the method shown, in
another thread, after the SecurityManager has authorized the
operation, but before the operation has taken place. (In C++,
of course, a random pointer can wreck havoc; a really clever
program could probably manage to find where the memory for the
deep copy was allocated, and modify it. It's considerably more
difficult than in Java, but it's certainly not impossible.)
If you want it secure, you
configure it one way; if you want to enable access by a debugger,
you configure it a different way. The language supports both.
Using the C++ model, you can have both at the same time. (I'm
pretty sure it would also be possible using the Java model---a
debugger integrated into the JVM would not need reflection.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]