Bug 47346 - access control for nested type is ignored in class template
Summary: access control for nested type is ignored in class template
Status: ASSIGNED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: Dodji Seketeli
URL:
Keywords: accepts-invalid
: 49388 50097 59081 59191 61816 (view as bug list)
Depends on:
Blocks: 59002
  Show dependency treegraph
 
Reported: 2011-01-18 15:15 UTC by Jonathan Wakely
Modified: 2015-05-05 07:28 UTC (History)
9 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2015-05-05 00:00:00


Attachments
Work in progress patch (5.17 KB, patch)
2011-08-11 18:52 UTC, Dodji Seketeli
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Wakely 2011-01-18 15:15:18 UTC
There are several bugs about failure to do access checking for template parameters and in function templates (PR 40901, PR 41437, PR 45011, PR 45917) but I don't think this is a dup of any of them

class C
{
  struct Private { };
};

template<typename T>
struct exploit1
{
    typedef C::Private type;
};

exploit1<int>::type x1;   // error

// similarly for base-specifier
template<typename T>
struct exploit2 : C::Private
{
};

exploit2<int> x2;   // error
Comment 1 Jonathan Wakely 2011-06-13 09:10:59 UTC
*** Bug 49388 has been marked as a duplicate of this bug. ***
Comment 2 Dodji Seketeli 2011-08-11 18:41:53 UTC
Another variation of the same theme is:

class C
{
    struct Private { };
};

template<typename T>
struct exploit3
{
    template<class U = C::Private>
    struct E {};
};

void
bar()
{
    exploit3<int>::E<> e;
}
Comment 3 Dodji Seketeli 2011-08-11 18:52:54 UTC
Created attachment 24985 [details]
Work in progress patch

I am currently testing this patch.

The problem I see is twofold.

First, the infrastructure I added a while back to do access checking of references to types, at template instantiation time,  was limited to typedefs.

This bug seems to suggest that the access checking should be done for references to all types.  Not just typedefs.

Second, add_typedef_to_current_template_for_access_check assumes that a "current template" is present.  When we are parsing the class header (for e.g the base clause) or the template parameter list, the "current template" is not present yet.  In that case, a possible solution is the stash away, for some short while, the types access that is to be checked, until the current template becomes available.

This is the approach taken by this patch.
Comment 4 Dodji Seketeli 2011-08-17 15:26:01 UTC
Candidate fix posted to http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01404.html
Comment 5 Paolo Carlini 2011-09-29 02:20:34 UTC
Out of curiosity, does the posted patch fix at once *all* the issues mentioned in the Description? It would be great to have it!
Comment 6 dodji@seketeli.org 2011-09-30 10:26:29 UTC
"paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org> a écrit:

> Out of curiosity, does the posted patch fix at once *all* the issues mentioned
> in the Description?

Yes it does, AFAICT.

> It would be great to have it!

I am onto something else at the moment, but I intend to address Jason's
comment to the patch I posted when I am done.  Sorry for the delay.
Comment 7 Paolo Carlini 2011-09-30 10:33:15 UTC
Great. By the way, I think I didn't see any comment, that's why I asked ;)
Comment 8 dodji@seketeli.org 2011-09-30 11:41:14 UTC
The comment was posted in another month:

http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00536.html

Another hint at why we need  a better patch/comments tracker :)
Comment 9 Paolo Carlini 2011-10-18 11:31:06 UTC
*** Bug 50097 has been marked as a duplicate of this bug. ***
Comment 10 Jason Merrill 2013-03-27 13:28:24 UTC
Even simpler:

class B { struct C {}; };
template <class T> struct A { B::C c; };
A<int> a;
Comment 11 Paolo Carlini 2013-07-06 23:42:39 UTC
Dodji, any news? ;)
Comment 12 Jonathan Wakely 2013-11-12 01:07:25 UTC
*** Bug 59081 has been marked as a duplicate of this bug. ***
Comment 13 Paolo Carlini 2013-11-19 16:28:10 UTC
*** Bug 59191 has been marked as a duplicate of this bug. ***
Comment 14 Andrew Pinski 2014-07-16 06:11:38 UTC
*** Bug 61816 has been marked as a duplicate of this bug. ***