bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

glibc shared image loader problem


From: m . brulisauer
Subject: glibc shared image loader problem
Date: Fri, 24 Nov 2000 17:22:19 +0100

Hi,

I had a mail thread with bob beck, the writer of smtpd and andreas schwab
of suse:

>>>>>> Hi,
>>>>>> I've just debugged smtpd. The problem i see is:
>>>>>> 
>>>>>>   smtpd is linked against some shared libraries
>>>>>>   located in /lib and /usr/lib. Without these
>>>>>>   libraries the gethostbyaddr() call does not
>>>>>>   work.
>>>>>>
>>>>>> My environemnt is: Linux/i686 and Linux/AXP.
>>>>>> I can see this problem on both of them.
>>>>>> Do you have a solution for this (except copying
>>>>>> the whole stuff into /var/spool/smtpd/lib and
>>>>>> /var/spool/smtpd/usr/lib; what I did now to
>>>>>> get the thing working)?

>>>>>      How are you starting smtpd? smtpd normally chroot's *after* it
starts 
>>>>> up, meaning those libraries should have already been linked, and it
should
>>>>> have the gethostbyaddr function. When you put those libraries in there
does
>>>>> it work for you? 
>>>>> 
>>>>>    My environment is OpenBSD/(many platforms) and I don't have this
problem. 
>>>>> 
>>>>>    -Bob

>>>> Hi Bob,
>>>> 
>>>> smtpd is started by inetd. inetd.conf looks like:
>>>> 
>>>>   smtp stream tcp nowait root /usr/sbin/smtpd smtpd -c /usr/spool/smtpd
-d / -u uucp -g uucp
>>>> 
>>>> When I put the libraries into the local (after chroot()) lib and
usr/lib
>>>> directory, it works fine. If you can't reproduce the problem, then I
will
>>>> ask SuSE. My installations are based on SuSE 6.3 linux distribution.
Per-
>>>> haps they know.
>>>> 
>>>> Martin

>>>       Well, that makes no sense at all, unless Linux's shared libary
>>> loader is not bringing the function in until the program uses it,
>>> which is very strange. with that invocation smtpd starts up, and of
>>> course, before running it, it's shared libraries are linked in. At
>>> that point, after starting, it chroot's itself to /usr/spool/smtpd, so
>>> unless linux's ld.so is strange you should not need to do this. 
>>> 
>>>        My suggesstion for a workaround is to change your compilation
>>> flags to compile smtpd statically, either that or put the libraries in
>>> the chroot (this is probably not harmful). If you do ask suse about
>>> it please include my note and e-mail on it. 
>>> 
>>>    Thanks,
>>>    -Bob

>> Hi Bob,
>> 
>> Linux's shared library loader is very strange. I have added
>> the following code to smtpd.c at line #2244
>> 
>>   #if defined(__linux__)
>>     {
>>       /*
>>       ** SuSE (and others?) Linux 6.3/6.4 (ld-2.1.2.so) patch:
>>       ** ld.so loads and maps shared images not at image startup.
>>       ** Shared images are mapped when first called. So call now
>>       ** gethostbyaddr() to load the reverse dns lookup modules.
>>       ** After chroot() this would fail as long as you don't copy
>>       ** the shared images to the local tree.
>>       ** 2000-11-22 Martin Brulisauer <address@hidden>
>>       */
>>       struct hostent *tmp_he;
>>       struct sockaddr_in tmp_addr;
>>       tmp_addr.sin_addr.s_addr = INADDR_LOOPBACK;
>>       tmp_he = gethostbyaddr((char *) &(tmp_addr.sin_addr.s_addr),
>>                        sizeof(tmp_addr.sin_addr.s_addr),
>>                        AF_INET);
>>     }
>>   #endif
>> 
>> This is shortly before you call chroot(). Now guess what - it works!
>> I realy don't know if loading images on demand at call time and
>> not at image startup is on purpose by the shared image loader dev
>> team. I will have a look into it's source as soon I find some time 
>> (by the way, you can find this strange side effects on linux in some
ftpd's
>> as well: they can't run /bin/ll).
>> 
>> Thank's for you help finding the bug and solving my problem.
>> 
>> With best regards,
>> Martin

> Hi Bob,
> I mailed with SuSE (Andreas Schwab, one of the members of the
> glibc team and asked him, if this is on purpose or not. He
> replied:
> 
>   Das is alles so gewollt, und ist auf jedem Glibc-System genauso.
> 
>   Andreas.
> 
>   -- 
>   Andreas Schwab                                  "And now for something
>   SuSE Labs                                        completely different."
>   address@hidden
>   SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
> 
> That means:
> 
>   "That's all on purpose and it's all like that on every glibc system."
> 
> So I suggest to add my code to your smtpd.c but not with the 
> #if defined(__linux__). Use #if defined(__GNUC__) instead
> (I'm not sure if this is correct, others use a Configure script to
> find out if glibc is used and define an own conditional in config.h).
> 
> That's all I have found.
> Greetings from switzerland
> Martin
>  

I think something is not consistent at all. If I look at /bin/ls on my
glibc system I can see:

  lts:~ # /lib/ld-linux.so.2 --list /bin/ls
          libc.so.6.1 => /lib/libc.so.6.1 (0x0000020000002000)
          /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0000020001000000)

When you have an anonymous ftp environment, ftpd starts /bin/ls after
chroot(). How can ls get the shared images now when changed the root
and no /lib exists? The shared image loader should be able to read
shared images without a chrooted access to the file system (like VMS,
the only OS I know that deep). Did I missunderstand something or is
here some work do be done?

Best Regards, 
              \\\ /// 
              ( @ @ ) 
----------oOOO--(_)--OOOo----------
Martin Brülisauer
Systems Enigneering 
Systime Informatik AG
Bruggacherstrasse 26
8117 Fällanden
SWITZERLAND
Tel: +(411) - 806 - 8650 
Fax: +(411) - 806 - 8622 
Email: address@hidden
-----------------------------------
 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]