220 10941 article Path: news.gmane.org!not-for-mail From: Diggory Blake Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Protect Lambda functions against reflection Date: Wed, 28 May 2014 16:14:23 -0700 (PDT) Lines: 325 Approved: news@gmane.org Message-ID: References: <108c47a2-d952-4f84-a347-923b2ab742ad@isocpp.org> <7ef3d3da-0c1d-443c-88d2-656b91937170@isocpp.org> <68f98b78-8bd4-48e0-9e1d-47cfc0492764@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2713_32309209.1401318863986" X-Trace: ger.gmane.org 1401318875 7586 80.91.229.3 (28 May 2014 23:14:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 May 2014 23:14:35 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC2MLAWQ6ANBBUO3TGOAKGQEBD2DWNY@isocpp.org Thu May 29 01:14:29 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vc0-f197.google.com ([209.85.220.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wpn3C-0004k4-Pr for gclcip-std-proposals@m.gmane.org; Thu, 29 May 2014 01:14:27 +0200 Original-Received: by mail-vc0-f197.google.com with SMTP id hy4sf6682119vcb.0 for ; Wed, 28 May 2014 16:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=y2KyXhJ7ZQhZdZ4eYt7FNu9IruvNDvxXek6W1PAErs0=; b=IasXpF+rNyYUdkrelqnAzPQJem02YGJOccMfzChH8QS79207vmfzjngfyAdnkPzQwY 48joVQQFcaYgO0l/zrIVTiqD/h/fS/oGINDesU2s0LI8bqh4ZQ4T6aqjF2/On7GbN/WS F0p0n4ajHZ1ibu3x+F42gs66WHMnf8Apopjh0H1/oXKrYPP3uzne26VaqAkpMqpCOFXm HalquX0WE8bNMU2LcO3ykToKh2mK51AtvK83RzmeRW37CvUhefogx5FneYSF70P+PJNf p82tBiTA8sC+Ibo3Rn56SeCpmowCWNpWYjShrHQpYsMjwiauAoO7E0jZ+LHpyc41bO+T vgfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=y2KyXhJ7ZQhZdZ4eYt7FNu9IruvNDvxXek6W1PAErs0=; b=A5usENqp3V4T7wVv4C2Iesrpwn5yWm/nz5vyA65u1NZVeqpSSMhci7RIc1J/4ty7v3 NBEFDJlEaNPfQxjfdJH/4fgOoINAbxGVG9ckpKB2/sP9HS9hDPZJYhWczCNpaWwujNuJ fc0mUuPexzv4qFO05RrTVbQTeeKACbH1PNyLrvkpGv3zraO5osQUqsMhqtNRUqBvEX9X 2yRUy2qd7fEIYbyfPZUnvlVAuUjSgFWMxemjZSo1fcbTdeBfBsZKl3Q/1ZMCGXea6d/a MTFvxUmq+PVuXqwjuf95aHxXMH/dXCxB5BC/1yf9TE3L9PRC0M5yGP8VUYG3BLlMPHkg bKlQ== X-Gm-Message-State: ALoCoQmdWzAfxF/xS8+VEQ38SxL1dEZ/9gMBUi3SaXb9+DgbkMZVqvj06XDhbWxmuZx8fyeyjmFR X-Received: by 10.236.231.52 with SMTP id k50mr1234645yhq.52.1401318865704; Wed, 28 May 2014 16:14:25 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.102.180 with SMTP id w49ls333367qge.3.gmail; Wed, 28 May 2014 16:14:24 -0700 (PDT) X-Received: by 10.140.47.201 with SMTP id m67mr54280qga.29.1401318864770; Wed, 28 May 2014 16:14:24 -0700 (PDT) In-Reply-To: X-Original-Sender: diggsey@googlemail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:10941 Archived-At: ------=_Part_2713_32309209.1401318863986 Content-Type: text/plain; charset=UTF-8 On Wednesday, 28 May 2014 23:18:02 UTC+1, Nevin ":-)" Liber wrote: > > On 28 May 2014 16:48, Diggory Blake >wrote: > >> >> >> On Wednesday, 28 May 2014 22:18:24 UTC+1, Nevin ":-)" Liber wrote: >> >>> On 28 May 2014 15:38, Diggory Blake wrote: >>> >>>> Also, access modifiers are not there for security reasons - it's >>>> trivial to bypass them if one really wanted to >>>> >>> >>> While there are a few places in the language where encapsulation is >>> broken (templated member functions, for instance), I don't think it is >>> trivial to bypass them in a *standard conforming* C++ program. Could >>> you give us some simple examples? >>> >> >> struct Foo { >> public: >> int m_public; >> private: >> int m_private; >> }; >> >> struct Bar { >> public: >> int m_public; >> int m_private; >> }; >> >> void setPrivate(Foo* foo, int v) { >> ((Bar*)foo)->m_private = v; >> } >> >> > And you are asserting that is a legal, standards conforming C++ program?? > Anything that generates undefined behavior is by definition not guaranteed > to generate the code you think it will generate. > No, but it does work in practically every C++ compiler ever. > > C++ allows direct memory access, of course it's trivial to bypass any kind >> of access control not enforced by the underlying operating system. >> > > I'm not arguing this from a security perspective (that would be silly), > but from a language perspective. > And the same people who are going to try accessing private members are not going to give up because their code isn't 100% standards compliant, if it works they'll do it. If you impose restrictions they'll find a way around them, and in the process you annoy every sane programmer who actually knows what they're doing. > > >> Just because a program is using reflection to enumerate private members >> does not imply that it is relying on implementation detail. >> > > If public/protected/private is ignored, how is reflection not exposing the > implementation details of the class? > > >> The program may be doing any number of tasks which the author of the >> class cannot possible have predicted, and the program may not require any >> kind of promise that the implementation will not change for it to succeed. >> > > And if I make an implementation change, I can break any of those tasks. > For exposed interface breaking changes, that's expected. You want to add > that ability for *any* class change; that makes things very fragile. > Really, so if I make a library which uses reflection to generate debug information for a program you can break it by changing your implementation? No. In addition, there are cases where the class author simply cannot foresee a use. For example, what if I want to generate memory layout information for a garbage collector such as Boehm to more precisely scan the heap? > > >> If the programmer was the one supplying these arguments then it would be >> pointless. The only time it's useful is if the programmer doesn't know what >> the arguments should be (ie. they are determined by the program at either >> compile-time or run-time). Access control only mitigates human error, so >> using it to restrict what the program itself can do has no benefit. >> > > Access control stops people from mucking with my invariants and relying on > a specific implementation. > Nope, it just tells them they shouldn't, and it will continue to do that even if it's possible to bypass it via reflection. > > >> -- >> > Nevin ":-)" Liber > (847) > 691-1404 > -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_2713_32309209.1401318863986 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wednesday, 28 May 2014 23:18:02 UTC+1, Nevin ":= -)" Liber wrote:
On 28 May 2014 16:48, Diggory Blake <dig...@googlemail.com> wrote:


On Wednesday, 28 May 2014 22:18:2= 4 UTC+1, Nevin ":-)" Liber wrote:
On 28 May 2014 15:38, Diggory Blake <dig...@googlemail.com> wrote:
Also, access modifiers are not there for = security reasons - it's trivial to bypass them if one really wanted to

While there are a few places in the langua= ge where encapsulation is broken (templated member functions, for instance)= , I don't think it is trivial to bypass them in a standard conforming C++ program.  Could you give us some simple examples?

=
struct Foo = {
public:
   = int m_public;
private:
   = ; int m_private;<= span style=3D"color:rgb(0,0,0)">
};

<= code>
struct Bar {
public:
   = int m_public;
    int m_private;
};

void setPrivate(Foo* foo, = int v) {
    ((Bar*)foo)->m_private =3D v;
}

<= br>
And you are asserting that is a legal, standards conforming C= ++ program??  Anything that generates undefined behavior is by definit= ion not guaranteed to generate the code you think it will generate.

No, but it does work in practically e= very C++ compiler ever.
 

C++ allows direct mem= ory access, of course it's trivial to bypass any kind of access control not= enforced by the underlying operating system.

I'm not arguing this from a se= curity perspective (that would be silly), but from a language perspective.<= /div>

And the same people who are go= ing to try accessing private members are not going to give up because their= code isn't 100% standards compliant, if it works they'll do it. If you imp= ose restrictions they'll find a way around them, and in the process you ann= oy every sane programmer who actually knows what they're doing.
 
 
Just because a program is using reflection to enumera= te private members does not imply that it is relying on implementation deta= il.

If public/protected/private= is ignored, how is reflection not exposing the implementation details of t= he class?
 
The program may be= doing any number of tasks which the author of the class cannot possible ha= ve predicted, and the program may not require any kind of promise that the = implementation will not change for it to succeed.

And if I make an implementatio= n change, I can break any of those tasks.  For exposed interface break= ing changes, that's expected.  You want to add that ability for *any* = class change; that makes things very fragile.

Really, so if I make a library which uses reflection to gen= erate debug information for a program you can break it by changing your imp= lementation? No. In addition, there are cases where the class author simply= cannot foresee a use. For example, what if I want to generate memory layou= t information for a garbage collector such as Boehm to more precisely scan = the heap?
 
 
If the programmer w= as the one supplying these arguments then it would be pointless. The only t= ime it's useful is if the programmer doesn't know what the arguments should= be (ie. they are determined by the program at either compile-time or run-t= ime). Access control only mitigates human error, so using it to restrict wh= at the program itself can do has no benefit.

Access control stops people from muc= king with my invariants and relying on a specific implementation.

Nope, it just tells them they shouldn't= , and it will continue to do that even if it's possible to bypass it via re= flection.
 
 
-- 
 Nevi= n ":-)" Liber  <mailto:ne...@e= viloverlord.com>  (847) 691-1404

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_2713_32309209.1401318863986-- .