Thread overview | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
October 24, 2012 Intended Security Hole? | ||||
---|---|---|---|---|
| ||||
From the docs, i.e. function.html:
> Functions without bodies [...] enable implementation to be completely hidden from the user of it.
This means also, that the implementation can be changed during runtime by "overriding" with another implementation, which might be malicious.
Why is it a good thing to rely on the reputability of an unknwon coder?
-manfred
|
October 24, 2012 Re: Intended Security Hole? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manfred Nowak | On Wednesday, 24 October 2012 at 16:59:11 UTC, Manfred Nowak wrote: > From the docs, i.e. function.html: > >> Functions without bodies [...] enable implementation to be >> completely hidden from the user of it. > > This means also, that the implementation can be changed during runtime > by "overriding" with another implementation, which might be malicious. > > Why is it a good thing to rely on the reputability of an unknwon coder? > > -manfred > Missing part of your quote that clarifies your post: > and that implementation will be provided at the link step. So, no, the implementation wouldn't be changed during runtime since it must be provided when linking. |
October 24, 2012 Re: Intended Security Hole? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris Cain | Chris Cain wrote: > So, no, the implementation wouldn't be changed during runtime since it must be provided when linking. Thats an expressed intent only. Reason: the linker does not know any thing about the language; the linker would be satisfied if there exists any function the linker can link to ... but the linker would not prohibit any replacement of that function during runtime. Conclusion: until a proof of the imposibility, there might exist cases in which such replacement is possible. Example for a _visible_ hijack: ----------------------------------------------------- private import std.stdio; abstract class Base { void foo(float f); } class Derived1 : Base { void foo(float f) { writefln("f =1= %f", f); } } class Derived2 : Base { void foo(float f) { writefln("f =2= %f", f); } } void main() { Base b; float f = 2.5; auto d1 = new Derived1; b= d1; b.foo( f); // f =1= 2.500000 auto d2= new Derived2; b= d2; b.foo( f); // f =2= 2.500000 } ----------------------------------------- Can be proved that it is impossible to make the assignment `b= d2;' invisible? -manfred |
October 24, 2012 Re: Intended Security Hole? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manfred Nowak | On Wednesday, 24 October 2012 at 21:07:28 UTC, Manfred Nowak wrote: > Chris Cain wrote: > >> So, no, the implementation wouldn't be changed during runtime since it must be provided when linking. > > Thats an expressed intent only. Reason: the linker does not know any > thing about the language; the linker would be satisfied if there > exists any function the linker can link to ... but the linker would > not prohibit any replacement of that function during runtime. If the code in question is statically linked, this is not a problem. If it's a shared library which is linked at runtime, then this is actually intended behavior and is used to create library shims. Here's an introduction to the technique: http://www.linuxjournal.com/article/7795 |
October 25, 2012 Re: Intended Security Hole? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manfred Nowak | On Wednesday, 24 October 2012 at 21:07:28 UTC, Manfred Nowak wrote: > Chris Cain wrote: > >> So, no, the implementation wouldn't be changed during runtime since it must be provided when linking. > > Thats an expressed intent only. Reason: the linker does not know any > thing about the language; the linker would be satisfied if there > exists any function the linker can link to ... but the linker would > not prohibit any replacement of that function during runtime. > > Conclusion: until a proof of the imposibility, there might exist > cases in which such replacement is possible. > > Example for a _visible_ hijack: > ----------------------------------------------------- > private import std.stdio; > > abstract class Base { > void foo(float f); > } > > class Derived1 : Base { > void foo(float f) { writefln("f =1= %f", f); } > } > class Derived2 : Base { > void foo(float f) { writefln("f =2= %f", f); } > } > > void main() { > Base b; > float f = 2.5; > > auto d1 = new Derived1; > b= d1; > b.foo( f); // f =1= 2.500000 > > auto d2= new Derived2; > b= d2; > b.foo( f); // f =2= 2.500000 > } > ----------------------------------------- What is wrong here? > Can be proved that it is impossible to make the assignment `b= d2;' > invisible? Assignment can be "invisible", for ex. if one of functions in _visible_ hijack.d is called from other module with derived class instance when base class instance is expected. But is not hijacking, it is inheriting. > -manfred |
October 25, 2012 Re: Intended Security Hole? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Justin Whear | Justin Whear wrote:
> is used to create library shims
One might be able to see: this is one of the roots of aspect programming.
As a system programming language, D should be able to support this paradigm like aspectC++ shows for c++.
Therefore: the answer to the subject is: yes.
-manfred
|
October 25, 2012 Re: Intended Security Hole? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Maxim Fomin | Maxim Fomin wrote: >> b= d2; > What is wrong here? The slight change in behavior might be unexpected and not intended for the owner of variable `Base b;'. What is the price ( i.e. coding time, execution time, execution space) the owner of that variable has to pay in the case that she/he want expectable behaviour only and owns the variable `b' but not the source of its type `Base' and has to provide some access to variable `b'? In essence: kills the ability of "aspect programming" the intent of "information hiding"? > But is not hijacking, it is inheriting. Variables can not be inhereted, only types. It seems to be euphemistic, to name "information steeling from" or "information changing of" a variable by the conceptual term "inheritance". -manfred |
October 25, 2012 Re: Intended Security Hole? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manfred Nowak | On Thursday, 25 October 2012 at 10:29:12 UTC, Manfred Nowak wrote: > Maxim Fomin wrote: > >>> b= d2; >> What is wrong here? > The slight change in behavior might be unexpected and not intended for > the owner of variable `Base b;'. Then disable behavior by marking class or function as a final. > What is the price ( i.e. coding time, execution time, execution space) > the owner of that variable has to pay in the case that she/he want > expectable behaviour only and owns the variable `b' but not the source > of its type `Base' and has to provide some access to variable `b'? > > In essence: kills the ability of "aspect programming" the intent of > "information hiding"? > >> But is not hijacking, it is inheriting. > Variables can not be inhereted, only types. It seems to be euphemistic, > to name "information steeling from" or "information changing of" a > variable by the conceptual term "inheritance". > > -manfred What is "information steeling from" and "information changing of" here? You deliberately created derived classes and passed instances of them where base class instances were expected. Why now you are complaining about this? You can use UFCS to do what you want (what I guess you want) because UFCS and virtual functions don't work now: http://dpaste.dzfl.pl/d6eafd71. But be hurry because UFCS admirers who found logic in making every feature work in accordance with UFCS can found this loophole. Also similar effect can be achieved by making functions private. BTW, you started thread with caution regarding replacing implementation of functions without bodies during runtime - please, provide an example how you can do this. |
October 25, 2012 Re: Intended Security Hole? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Maxim Fomin | Maxim Fomin wrote: > Then disable behavior by marking class or function as a final. Do you really mean by this, that "aspect programming" is impossible in D? Or that marking `final' is enough? > provide an example how you can do this. I was in fear and posted an approach. But I was not sure. Therefore I asked for a proof, that my fear had not cause in reality. Your demand for an example only expresses, that you too are guided by expectations only, not by proofs. - manfred |
October 25, 2012 Re: Intended Security Hole? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Maxim Fomin | Maxim Fomin wrote: > Why now you are complaining about this? Because this is the learn group and I did not realize, that the compiler does conform to the definition of "overload resolution" in function.html#function-inheritance, i.e. my expectation is defined as a bug. - manfred |
Copyright © 1999-2021 by the D Language Foundation