Globals visible in shared object libraries

[Gaurav Jain]

Hi Scott,

I can't reproduce your problem in a small program.  Can you give your
source code that's failing?

Gaurav

On 6/13/05, Weber, Scott <Scott.Weber@vectorsgi.com> wrote:
> Thanks for the tip.  I am not using RTLD_GLOBAL.  And it appears
> there is no real definition for RTLD_LOCAL  (i.e. 0x0000)
> 
> Forgot to mention, I can make B.so declaration 'static short value'
> and solve the problem.  But that's not the fix I want.
> But I'm concerned about the main execuable being corrupted by
> the shared libs, which are to be created by anybody.
> 
> I want to secure the main executable, not tell dozens of people
> they have to code the sared module a specific way, and have to
> keep up with all the vendors everytime there is a problem.
> 
> Who gets the 'fvisibility' flag?  And does it apply if I'm not
> using the RTLD_GLOBAL flag?
> 
> -----Original Message-----
> From: Keith, Robert (London) [mailto:robert_keith@ml.com]
> Sent: Monday, June 13, 2005 11:26 AM
> To: Weber, Scott; gcc-help@gcc.gnu.org
> Subject: RE: Globals visible in shared object libraries
> 
> 
> I have had a similar problem with functions. After much searching the
> result is as follows
> 
> 1. Don't Load the module with RTLD_GLOBAL, which is what it sounds like
> you are doing. If you absolutely have to do this then depending on the
> version of the compiler that you are using I would recommend compiling
> the code with the -fvisibility=hidden and making sure you only call
> functions that you have extern'ed when calling across shared library
> boundaries. This switch makes all symbols part of the local (dll/so)
> namespace when its loaded and only pushes symbols you have explicitly
> declared as global in to the global namespace.
> 
> 2.Another alternative is to put the following in front of your
> declaration for 'value'
> 
> __attribute__ ((visibility("hidden")))
> 
> This will only be honoured if your compiler has had this functionality
> included (or back ported). Basically this tells the compiler to look in
> the local namespace then the global namespace when attempting to resolve
> symbols using shared libraries. I honestly don't know what version this
> was officially included in the compiler (I think it was 3.4, since it
> has been back ported to many compilers even 3.2.3)
> 
> So that's the quick fix - more information can be found at:
> 
> http://gcc.gnu.org/wiki/Visibility
> 
> And
> 
> http://www.google.co.uk/url?sa=U&start=1&q=http://people.redhat.com/drep
> per/dsohowto.pdf&e=10431
> 
> 3. Namespace the variable in each so and make sure that the functions
> that update it reference it via the correct name space.
> 
> E.g. namespace a {
>         value ;
> }
> void someFunc() {
>                 a::value = 10 ;
> }
> 
> namespace b {
>         value ;
> }
> 
> Void someOtherFunc() {
>         b::value = 21 ;
> }
> 
> Regards,
> 
> Robert Keith
> 
> 
> -----Original Message-----
> From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
> Behalf Of Weber, Scott
> Sent: 13 June 2005 17:13
> To: gcc-help@gcc.gnu.org
> Subject: Globals visible in shared object libraries
> 
> 
> 
> I have been digging at this for days, Now I'm turning to the experts.
> 
> Given:
> executable module A has a global variable (long)  called 'value' It
> loads module B.so  using dlopen() and loads a function pointer (called
> 'test') .
> 
> Module B.so also has a global variable (some other type) called 'value'
> 
> When I call test() in B.so and that function changes the contents of
> 'value', it
> changes to one in the A executable.  Not the one in in B.so.  (or I
> assume they have been 'linked' into the same memory location)
> 
> How can I DISABLE the dynamic linker from doing what appears to be
> binding the variable 'value'  in the two modules together?  It's this a
> HUGH hole where any shared library can get access to (and corrupt)
> variables in the main executable?
> 
> Everything think I've seen written seems to be regarding doing the
> opposite.
> 
> Any help is appreciated.
> 
> -Scott Weber
> (sorry if this is not exclusively plain text - Outlook... :-(  )
> --------------------------------------------------------
> 
> If you are not an intended recipient of this e-mail, please notify the
> sender, delete it and do not read, act upon, print, disclose, copy,
> retain or redistribute it. Click here for important additional terms
> relating to this e-mail.     http://www.ml.com/email_terms/
> --------------------------------------------------------
>