220 10953 article Path: news.gmane.org!not-for-mail From: Cleiton Santoia Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Protect Lambda functions against reflection Date: Thu, 29 May 2014 03:02:49 -0700 (PDT) Lines: 261 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_4473_3522701.1401357769555" X-Trace: ger.gmane.org 1401357782 30191 80.91.229.3 (29 May 2014 10:03:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 May 2014 10:03:02 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCBMVWMTUUNBBS4LTSOAKGQEPFMTFPA@isocpp.org Thu May 29 12:02:54 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f200.google.com ([209.85.214.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WpxAi-0002j0-My for gclcip-std-proposals@m.gmane.org; Thu, 29 May 2014 12:02:53 +0200 Original-Received: by mail-ob0-f200.google.com with SMTP id wo20sf442487obc.3 for ; Thu, 29 May 2014 03:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=zIJAgfQEWcYKP7QWMhL5p+8bSlD0PlhUEKk5hlAmXFM=; b=EA7XQstUnfZExltBXksgYwAtMkNTqgP9xR+MzyQ9qC+zAFfyxCKPnGN6OCSdKYm9tK py8KXuO+7gh6tJ4FQvaHrhUlISaIET4XAHI7O8p72BxIUJ7q0WAF60NKPA/IMajN2UrX eqcHEnC26Y3tOg8VXHWIibqBQr1M2J4nmlo96Cy3FqRFWxnXCk1p7LEJ37lStJHXcNo1 7yNdolMACTIF4tZFJ2VywUruH+LNBqbkCYRCdjKMec7d5HEjDotITl0mNK51QKUG+zZr vspqyxHUuAG5Bp9/BQlwphSzMD7FjG3I9clGGz6NLWHR7cv25agdwl5MqRfVLkO2LkGH Erjg== 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=zIJAgfQEWcYKP7QWMhL5p+8bSlD0PlhUEKk5hlAmXFM=; b=L71rMm5CnB038PdCCwyMtBG9ea4K9hhSg/Jj/FDbz4GgQT9rboHIOVqjOfVZYTD8TQ 0UFeRJtSC7tEIfKgvzUHbQ/jmTT+th6SiX+WtaEjeez/SGyRLBUKy/HnYPfQ/Mwj8qM+ kAUvE96uoBjLlkDjh2tmr6HzWAvoeNZbAJObmXEdxi34x5Yi0S53Jzue4jJ1/+d09cPx ofqd+7EQV6M7NzOeIGj/0uzNLBR8gb+5RJx/Itkpj59cEkaqxVX/fA7OfCcSBC+FHU3o PX3Tugdy4i/2AnoHaO7qqa17l/RXKfEHuWGA2Hd0xV+vC/boAyfHfJX4+sUFxVvKrASN lK5A== X-Gm-Message-State: ALoCoQl/cZNrwec+0/jEUxF+hAvECH66lW29dSWsbn47rO+FRgLkkCb5U4fQiDz0GPy8fge4rtNi X-Received: by 10.43.156.13 with SMTP id lk13mr2355350icc.29.1401357771795; Thu, 29 May 2014 03:02:51 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.85.40 with SMTP id m37ls490387qgd.18.gmail; Thu, 29 May 2014 03:02:51 -0700 (PDT) X-Received: by 10.140.100.204 with SMTP id s70mr119048qge.9.1401357771029; Thu, 29 May 2014 03:02:51 -0700 (PDT) In-Reply-To: X-Original-Sender: cleitonsantoia@gmail.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:10953 Archived-At: ------=_Part_4473_3522701.1401357769555 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's not good someone messing with the class invariants, so you should not= =20 access private members, however, as Herb always remember us, you should be= =20 able to look under the hood. So, what is intended in N3951 is by default do not violate access=20 specification: class A { typedef // see all from A; }; class B : public A { typedef // see protected and public from A; }; class C { typedef // see public from A; }; I don=C2=B4t let anyone looking my private members, unless if you buy me a = drink=20 first and ask nicely "typedef" I will let you= =20 see my private parts; // trait from N3987 BR Cleiton Em quarta-feira, 28 de maio de 2014 19h27min36s UTC-3, Jeffrey Yasskin=20 escreveu: > > On Wed, May 28, 2014 at 2:48 PM, Diggory Blake >=20 > wrote:=20 > >=20 > >=20 > > On Wednesday, 28 May 2014 22:18:24 UTC+1, Nevin ":-)" Liber wrote:=20 > >>=20 > >> On 28 May 2014 15:38, Diggory Blake wrote:=20 > >>>=20 > >>> Also, access modifiers are not there for security reasons - it's=20 > trivial=20 > >>> to bypass them if one really wanted to=20 > >>=20 > >>=20 > >> While there are a few places in the language where encapsulation is=20 > broken=20 > >> (templated member functions, for instance), I don't think it is trivia= l=20 > to=20 > >> bypass them in a standard conforming C++ program. Could you give us= =20 > some=20 > >> simple examples?=20 > >=20 > >=20 > > struct Foo {=20 > > public:=20 > > int m_public;=20 > > private:=20 > > int m_private;=20 > > };=20 > >=20 > > struct Bar {=20 > > public:=20 > > int m_public;=20 > > int m_private;=20 > > };=20 > >=20 > > void setPrivate(Foo* foo, int v) {=20 > > ((Bar*)foo)->m_private =3D v;=20 > > }=20 > >=20 > > C++ allows direct memory access, of course it's trivial to bypass any= =20 > kind=20 > > of access control not enforced by the underlying operating system.=20 > > This violates basic.lval's aliasing restrictions, which causes=20 > undefined behavior. It also relies on the compiler not taking=20 > advantage of the permission to reorder things at access control=20 > boundaries. That's why Nevin specified "standard conforming". It's=20 > true that malicious code within a single process can, in practice, use=20 > undefined behavior to get whatever behavior it wants, but undefined=20 > behavior still affects who's blamed for breakage.=20 > > >>> Since reflection is a tool used by the program, not the programmer,= =20 > >>=20 > >>=20 > >> Huh?=20 > >=20 > >=20 > > The purpose of reflection is not to do this (pseudocode):=20 > > findClass("Foo").construct("Hello, world!")=20 > >=20 > > Instead of just:=20 > > new Foo("Hello, world!")=20 > >=20 > > If the programmer was the one supplying these arguments then it would b= e=20 > > pointless.=20 > > If Foo's constructor is private, but reflection allows access to it=20 > anyway, people will use reflection to get access to it, and the people=20 > trying to maintain Foo will curse us the next time they try to upgrade=20 > it. You saying that's not the purpose won't stop any of that from=20 > happening.=20 > > That said, I think I do prefer reflection to ignore access control,=20 > and not to provide an escape hatch for class authors. If class authors=20 > can't explicitly block reflection, it'll be a bit easier for them to=20 > place the blame on the "nitwits" where it belongs. :)=20 > > Jeffrey=20 > --=20 ---=20 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 e= mail 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-proposa= ls/. ------=_Part_4473_3522701.1401357769555 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It's not good someone messing with the= class invariants, so you should not access private members, however, as He= rb always remember us, you should be able to look under the hood.

So, what is intended in N3951 is by default do not violate = access specification:

class A {
typedef&= lt;A> // see all from A;
};

class B := public A {
typedef<A> // see protected and public from A;<= /div>
};

class C  {
typede= f<A> // see public from A;
};

I don=C2=B4t let anyone looking my private members, unless if you bu= y me a drink first and ask nicely "typedef<A requires std::is_private>= ;" I will let you see my private parts;   // trait from N3987


BR
Cleiton



= Em quarta-feira, 28 de maio de 2014 19h27min36s UTC-3, Jeffrey Yasskin esc= reveu:
On Wed, May 28, 2014 at = 2:48 PM, Diggory Blake <dig...@goog= lemail.com> wrote:
>
>
> On Wednesday, 28 May 2014 22:18:24 UTC+1, Nevin ":-)" Liber wrote:
>>
>> On 28 May 2014 15:38, Diggory Blake <dig...@googlemail.c= om> 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 encapsulati= on is broken
>> (templated member functions, for instance), I don't think it i= s 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 =3D v;
> }
>
> C++ allows direct memory access, of course it's trivial to bypass = any kind
> of access control not enforced by the underlying operating system.

This violates basic.lval's aliasing restrictions, which causes
undefined behavior. It also relies on the compiler not taking
advantage of the permission to reorder things at access control
boundaries. That's why Nevin specified "standard conforming". It's
true that malicious code within a single process can, in practice, use
undefined behavior to get whatever behavior it wants, but undefined
behavior still affects who's blamed for breakage.

>>> Since reflection is a tool used by the program, not the pr= ogrammer,
>>
>>
>> Huh?
>
>
> The purpose of reflection is not to do this (pseudocode):
> findClass("Foo").construct("Hello, world!")
>
> Instead of just:
> new Foo("Hello, world!")
>
> If the programmer was the one supplying these arguments then it wo= uld be
> pointless.

If Foo's constructor is private, but reflection allows access to it
anyway, people will use reflection to get access to it, and the people
trying to maintain Foo will curse us the next time they try to upgrade
it. You saying that's not the purpose won't stop any of that from
happening.

That said, I think I do prefer reflection to ignore access control,
and not to provide an escape hatch for class authors. If class authors
can't explicitly block reflection, it'll be a bit easier for them to
place the blame on the "nitwits" where it belongs. :)

Jeffrey

--

---
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_4473_3522701.1401357769555-- .