ldd fails when dll has no execute permissions

ldd fails when dll has no execute permissions

[cppjavaperl]

This was discovered in cygwin-1.7.10-1.

If you run 'ldd' against an executable, and the executable has dependent DLLs which do *not* have execute permissions, ldd's output stops when it reaches the offending dependent DLL, and reports no further information.  ldd does not give an error message, and the exit code is zero.

To test, pick an application with a dependent DLL, then chmod 666 on that DLL (pick a DLL you can live without temporarily, of course), then run 'ldd' against the executable.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: ldd fails when dll has no execute permissions

[Corinna Vinschen]

On Feb 23 15:03, cppjavaperl wrote:
> This was discovered in cygwin-1.7.10-1.
> 
> If you run 'ldd' against an executable, and the executable has
> dependent DLLs which do *not* have execute permissions, ldd's output
> stops when it reaches the offending dependent DLL, and reports no
> further information.  ldd does not give an error message, and the exit
> code is zero.

DLL's must have execute permissions to be loaded into the process.
And that is what ldd does, it starts a process and inspects the
process memory to see what DLLs are loaded via the Win32 debug API.

The problem is that the Win32 loader stops loading as soon as it
encounters the non-executable DLL.  So there will simply be no further
LOAD_DLL_DEBUG_EVENT.  The next event is an EXIT_PROCESS_DEBUG_EVENT
which means to ldd that it collected all DLLs and so it just prints
the list of so far collected DLLs.

I don't see how this could be changed to behave differently in this
case.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: ldd fails when dll has no execute permissions

[Christopher Faylor]

On Thu, Feb 23, 2012 at 03:03:40PM -0800, cppjavaperl wrote:
>This was discovered in cygwin-1.7.10-1.
>
>If you run 'ldd' against an executable, and the executable has
>dependent DLLs which do *not* have execute permissions, ldd's output
>stops when it reaches the offending dependent DLL, and reports no
>further information.?  ldd does not give an error message, and the exit
>code is zero.
>
>To test, pick an application with a dependent DLL, then chmod 666 on
>that DLL (pick a DLL you can live without temporarily, of course), then
>run 'ldd' against the executable.

Can't reproduce this (with the latest DLL from the snapshot):

bash$ chmod a-w /bin/*.dll
bash$ ldd /bin/pwd
        ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x779a0000)
        kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75310000)
        KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ae0000)
        cygwin1.dll => /usr/bin/cygwin1.dll (0x61000000)
        cygintl-8.dll => /usr/bin/cygintl-8.dll (0x61730000)
        cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x63c10000)

Given how ldd works, it's hard to see why executable permissions should
affect it.  ldd starts the executable for debugging and tracks .dlls as
they are loaded.  The executable bit state should have no effect on
that.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: ldd fails when dll has no execute permissions

[Christopher Faylor]

On Fri, Feb 24, 2012 at 03:42:33PM -0500, Christopher Faylor wrote:
>On Thu, Feb 23, 2012 at 03:03:40PM -0800, cppjavaperl wrote:
>>This was discovered in cygwin-1.7.10-1.
>>
>>If you run 'ldd' against an executable, and the executable has
>>dependent DLLs which do *not* have execute permissions, ldd's output
>>stops when it reaches the offending dependent DLL, and reports no
>>further information.?  ldd does not give an error message, and the exit
>>code is zero.
>>
>>To test, pick an application with a dependent DLL, then chmod 666 on
>>that DLL (pick a DLL you can live without temporarily, of course), then
>>run 'ldd' against the executable.
>
>Can't reproduce this (with the latest DLL from the snapshot):
>
>bash$ chmod a-w /bin/*.dll
>bash$ ldd /bin/pwd
>        ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x779a0000)
>        kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75310000)
>        KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ae0000)
>        cygwin1.dll => /usr/bin/cygwin1.dll (0x61000000)
>        cygintl-8.dll => /usr/bin/cygintl-8.dll (0x61730000)
>        cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x63c10000)
>
>Given how ldd works, it's hard to see why executable permissions should
>affect it.  ldd starts the executable for debugging and tracks .dlls as
>they are loaded.  The executable bit state should have no effect on
>that.

Nevermind.  Obviously I typoed the a-w and, so, my test is not going to
do anything.  Corinna's answer is the correct one.

Sorry for the noise.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: ldd fails when dll has no execute permissions

[Corinna Vinschen]

On Feb 24 15:42, Christopher Faylor wrote:
> On Thu, Feb 23, 2012 at 03:03:40PM -0800, cppjavaperl wrote:
> >This was discovered in cygwin-1.7.10-1.
> >
> >If you run 'ldd' against an executable, and the executable has
> >dependent DLLs which do *not* have execute permissions, ldd's output
> >stops when it reaches the offending dependent DLL, and reports no
> >further information.?  ldd does not give an error message, and the exit
> >code is zero.
> >
> >To test, pick an application with a dependent DLL, then chmod 666 on
> >that DLL (pick a DLL you can live without temporarily, of course), then
> >run 'ldd' against the executable.
> 
> Can't reproduce this (with the latest DLL from the snapshot):
> 
> bash$ chmod a-w /bin/*.dll

Try chmod -x instead of -w.  And do that only to a single DLL or
be prepared to suffer.

> bash$ ldd /bin/pwd
>         ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x779a0000)
>         kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75310000)
>         KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ae0000)
>         cygwin1.dll => /usr/bin/cygwin1.dll (0x61000000)
>         cygintl-8.dll => /usr/bin/cygintl-8.dll (0x61730000)
>         cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x63c10000)
> 
> Given how ldd works, it's hard to see why executable permissions should
> affect it.  ldd starts the executable for debugging and tracks .dlls as
> they are loaded.  The executable bit state should have no effect on
> that.

It has.  Windows only loads DLLs into executables if the execute bit
is set.  Here's what I did for testing:

  From tcsh, because I removed the execute bit from one of the DLLs
  used by bash:

   tcsh> ldd /bin/bash
        ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x77a30000)
        kernel32.dll => /cygdrive/c/Windows/system32/kernel32.dll (0x75ec0000)
        KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll (0x75cd0000)
        cygwin1.dll => /usr/bin/cygwin1.dll (0x61000000)
        cygintl-8.dll => /usr/bin/cygintl-8.dll (0x68580000)
        cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x69460000)
        cygreadline7.dll => /usr/bin/cygreadline7.dll (0x67550000)
        cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x6bb40000)
        cygncursesw-10.dll => /usr/bin/cygncursesw-10.dll (0x66920000)
        USER32.dll => /cygdrive/c/Windows/system32/USER32.dll (0x776d0000)
        GDI32.dll => /cygdrive/c/Windows/system32/GDI32.dll (0x75fc0000)
        LPK.dll => /cygdrive/c/Windows/system32/LPK.dll (0x773c0000)
        USP10.dll => /cygdrive/c/Windows/system32/USP10.dll (0x777a0000)
        msvcrt.dll => /cygdrive/c/Windows/system32/msvcrt.dll (0x775c0000)
        IMM32.DLL => /cygdrive/c/Windows/system32/IMM32.DLL (0x77670000)
        MSCTF.dll => /cygdrive/c/Windows/system32/MSCTF.dll (0x77840000)
   tcsh> chmod -x /bin/cygreadline7.dll
   tcsh> ldd /bin/bash
        ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x77a30000)
        kernel32.dll => /cygdrive/c/Windows/system32/kernel32.dll (0x75ec0000)
        KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll (0x75cd0000)
        cygwin1.dll => /usr/bin/cygwin1.dll (0x61000000)
        cygintl-8.dll => /usr/bin/cygintl-8.dll (0x68580000)
        cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x69460000)


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: ldd fails when dll has no execute permissions

[Christopher Faylor]

On Wed, Mar 07, 2012 at 11:04:35AM -0800, cppjavaperl wrote:
>On Wed, Mar 07, 2012 at 12:57:03 -0500, Christopher Faylor wrote:
>>I'll try to be clearer.  We obviously know how to scan an executable
>>for dependent DLLs since cygcheck does it already (and actually cygwin
>>itself does this) but we are not going to be modifying ldd to deal with
>>the case of non-executable binaries.
>
>I was not aware (until seeing it discussed elsewhere, shortly after my
>last post) that cygcheck had this capability already.
>
>So, correct me if I'm wrong, it really doesn't have anything to do with
>mirroring ldd's behavior on Linux -- It's just that you don't view it
>as a problem worth spending time on.

I tested linux and found that it failed on a binary with no executable
privileges.  I didn't go to the extra effort of trying to make dependent
.so's nonexecutable.  But, I have confirmed that it is unaffected if a
dependent .so is executable.  So I can't claim that this is completely
a linux compatibility feature.

But, yes, you are correct that I don't think it's worthwhile to rewrite
ldd to deal with this issue.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: ldd fails when dll has no execute permissions

[cppjavaperl]

On Wed, Mar 07, 2012 at 12:57:03 -0500, Christopher Faylor wrote:

> I'll try to be clearer.  We obviously know how to scan an executable for
> dependent DLLs since cygcheck does it already (and actually cygwin
> itself does this) but we are not going to be modifying ldd to deal with
> the case of non-executable binaries.

I was not aware (until seeing it discussed elsewhere, shortly after my last post) that cygcheck had this capability already.

So, correct me if I'm wrong, it really doesn't have anything to do with mirroring ldd's behavior on Linux -- It's just that you don't view it as a problem worth spending time on.

Fair enough.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: ldd fails when dll has no execute permissions

[Christopher Faylor]

On Wed, Mar 07, 2012 at 09:26:39AM -0800, cppjavaperl wrote:
>Then I tried it on an old machine running SuSE 9.0 (kernel 2.4.21, even).
>In this case, ldd fails only if the *program's* executable has no execute 
>permissions.? The dependent DLLs are not required to have executable 
>permissions -- all the dependent DLLs were enumerated whether they had the
>executable permissions or not.

I'll try to be clearer.  We obviously know how to scan an executable for
dependent DLLs since cygcheck does it already (and actually cygwin
itself does this) but we are not going to be modifying ldd to deal with
the case of non-executable binaries.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: ldd fails when dll has no execute permissions

[cppjavaperl]

sorry about the extra question marks my last post.  I'm not sure what caused them.  Yahoo's email interface didn't show them when it was sent, and they don't appear in the copy of the message in my Sent folder.  Weird.  (of course, now this post will probably end up having them also :-D )


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: ldd fails when dll has no execute permissions

[cppjavaperl]

On Mar 6 20:51, Christopher Faylor wrote:

> On Tue, Mar 06, 2012 at 03:53:34PM -0800, cppjavaperl wrote:
> > > On Feb 24 12:56, Corinna Vinschen wrote:
> > >
> > > On Feb 23 15:03, cppjavaperl wrote:
> > > > This was discovered in cygwin-1.7.10-1.
> > > > 
> > > > If you run 'ldd' against an executable, and the executable has 
> > > > dependent DLLs which do *not* have execute permissions, ldd's output
> > > > stops when it reaches the offending dependent DLL, and reports no
> > > > further information.? ldd does not give an error message, and the exit
> > > > code is zero.
> > > 
> > > DLL's must have execute permissions to be loaded into the process.
> > > And that is what ldd does, it starts a process and inspects the 
> > > process memory to see what DLLs are loaded via the Win32 debug API.
> > > 
> > > The problem is that the Win32 loader stops loading as soon as it
> > > encounters the non-executable DLL.  So there will simply be no further
> > > LOAD_DLL_DEBUG_EVENT.  The next event is an EXIT_PROCESS_DEBUG_EVENT
> > > which means to ldd that it collected all DLLs and so it just prints
> > > the list of so far collected DLLs.
> > > 
> > > I don't see how this could be changed to behave differently in this
> > > case.
> > > 
> > > 
> > > Corinna
> > > 
> >
> > Sorry I just got back to this topic.  After a little research, I found
> > this old link which discusses a similar type tool provided by Microsoft:
> > 
> > http://www.mail-archive.com/delphi@delphi.org.nz/msg11393.html
> > 
> > After reading that thread, I downloaded the code from Microsofts ftp site
> > here:
> > 
> > ftp://ftp.microsoft.com/softlib/mslfiles/MSJFEB97.EXE
> > 
> > The code looks reasonable, and doesn't appear to be difficult at all to 
> > follow.  Running the executable in testing like I did with ldd gives
> > better results (IMHO).  It finds the dependent DLLs even if the executable
> > bit is not set, and it continues looking for DLLs when it can't find one,
> > while noting each DLL that can't be found.
> > 
> > Perhaps it would be good to use this sample code to make modifications
> > to ldd, so that it could give more accurate information.  I do not know
> > if there are any situations where the Microsoft sample code would 
> > provide inaccurate information, and perhaps there are situations I'm not 
> > aware of where the existing ldd code would work and the Microsoft code
> > would not.  However, it seems to me that the Microsoft code is worth
> > looking at -- in order to consider improving ldd.  The Microsoft code
> > doesn't appear to me to be restricted in any way that would hinder its use 
> > in ldd.
> > 
> > It seems to me that the ideal solution would list all the DLLs, 
> > noting which could not be found, and also giving a warning if a DLL
> > is not executable.  Perhaps that kind of solution could be achieved by
> > modifiying ldd using Microsoft's sample code as an example.
> 
> ldd.exe is not going to change.  ldd on linux is also unable to display
> dependencies unless the thing being checked has executable permissions.

"ldd on linux is also unable to display dependencies unless the thing being
checked has executable permissions." -- Actually, that isn't true (at least,
not for all versions of ldd on Linux).  I tried running ldd against an
executable with a dependent DLL (both of which did not have executable
permissions), and on both CentOS 6.0 and Debian squeeze (6.0.4) I got this
warning:

  "ldd: warning: you do not have execution permission for [executable-name]" 

but they *did* print out the dependent DLLs (including the one with no 
executable permissions).

Then I tried it on an old machine running SuSE 9.0 (kernel 2.4.21, even).
In this case, ldd fails only if the *program's* executable has no execute 
permissions.  The dependent DLLs are not required to have executable 
permissions -- all the dependent DLLs were enumerated whether they had the
executable permissions or not.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: ldd fails when dll has no execute permissions

[Christopher Faylor]

On Tue, Mar 06, 2012 at 03:53:34PM -0800, cppjavaperl wrote:
>> On Feb 24 12:56, Corinna Vinschen wrote:
>>
>> On Feb 23 15:03, cppjavaperl wrote:
>> > This was discovered in cygwin-1.7.10-1.
>> > 
>> > If you run 'ldd' against an executable, and the executable has 
>> > dependent DLLs which do *not* have execute permissions, ldd's output
>> > stops when it reaches the offending dependent DLL, and reports no
>> > further information.? ldd does not give an error message, and the exit
>> > code is zero.
>> 
>> DLL's must have execute permissions to be loaded into the process.
>> And that is what ldd does, it starts a process and inspects the 
>> process memory to see what DLLs are loaded via the Win32 debug API.
>> 
>> The problem is that the Win32 loader stops loading as soon as it
>> encounters the non-executable DLL.  So there will simply be no further
>> LOAD_DLL_DEBUG_EVENT.  The next event is an EXIT_PROCESS_DEBUG_EVENT
>> which means to ldd that it collected all DLLs and so it just prints
>> the list of so far collected DLLs.
>> 
>> I don't see how this could be changed to behave differently in this
>> case.
>> 
>> 
>> Corinna
>> 
>
>Sorry I just got back to this topic.  After a little research, I found
>this old link which discusses a similar type tool provided by Microsoft:
>
>http://www.mail-archive.com/delphi@delphi.org.nz/msg11393.html
>
>After reading that thread, I downloaded the code from Microsofts ftp site
>here:
>
>ftp://ftp.microsoft.com/softlib/mslfiles/MSJFEB97.EXE
>
>The code looks reasonable, and doesn't appear to be difficult at all to 
>follow.  Running the executable in testing like I did with ldd gives
>better results (IMHO).  It finds the dependent DLLs even if the executable
>bit is not set, and it continues looking for DLLs when it can't find one,
>while noting each DLL that can't be found.
>
>Perhaps it would be good to use this sample code to make modifications
>to ldd, so that it could give more accurate information.  I do not know
>if there are any situations where the Microsoft sample code would 
>provide inaccurate information, and perhaps there are situations I'm not 
>aware of where the existing ldd code would work and the Microsoft code
>would not.  However, it seems to me that the Microsoft code is worth
>looking at -- in order to consider improving ldd.  The Microsoft code
>doesn't appear to me to be restricted in any way that would hinder its use 
>in ldd.
>
>It seems to me that the ideal solution would list all the DLLs, 
>noting which could not be found, and also giving a warning if a DLL
>is not executable.  Perhaps that kind of solution could be achieved by
>modifiying ldd using Microsoft's sample code as an example.

ldd.exe is not going to change.  ldd on linux is also unable to display
dependencies unless the thing being checked has executable permissions.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: ldd fails when dll has no execute permissions

[cppjavaperl]

> On Feb 24 12:56, Corinna Vinschen wrote:
>
> On Feb 23 15:03, cppjavaperl wrote:
> > This was discovered in cygwin-1.7.10-1.
> > 
> > If you run 'ldd' against an executable, and the executable has 
> > dependent DLLs which do *not* have execute permissions, ldd's output
> > stops when it reaches the offending dependent DLL, and reports no
> > further information. ldd does not give an error message, and the exit
> > code is zero.
> 
> DLL's must have execute permissions to be loaded into the process.
> And that is what ldd does, it starts a process and inspects the 
> process memory to see what DLLs are loaded via the Win32 debug API.
> 
> The problem is that the Win32 loader stops loading as soon as it
> encounters the non-executable DLL.  So there will simply be no further
> LOAD_DLL_DEBUG_EVENT.  The next event is an EXIT_PROCESS_DEBUG_EVENT
> which means to ldd that it collected all DLLs and so it just prints
> the list of so far collected DLLs.
> 
> I don't see how this could be changed to behave differently in this
> case.
> 
> 
> Corinna
> 

Sorry I just got back to this topic.  After a little research, I found
this old link which discusses a similar type tool provided by Microsoft:

http://www.mail-archive.com/delphi@delphi.org.nz/msg11393.html

After reading that thread, I downloaded the code from Microsofts ftp site
here:

ftp://ftp.microsoft.com/softlib/mslfiles/MSJFEB97.EXE

The code looks reasonable, and doesn't appear to be difficult at all to 
follow.  Running the executable in testing like I did with ldd gives
better results (IMHO).  It finds the dependent DLLs even if the executable
bit is not set, and it continues looking for DLLs when it can't find one,
while noting each DLL that can't be found.

Perhaps it would be good to use this sample code to make modifications
to ldd, so that it could give more accurate information.  I do not know
if there are any situations where the Microsoft sample code would 
provide inaccurate information, and perhaps there are situations I'm not 
aware of where the existing ldd code would work and the Microsoft code
would not.  However, it seems to me that the Microsoft code is worth
looking at -- in order to consider improving ldd.  The Microsoft code
doesn't appear to me to be restricted in any way that would hinder its use 
in ldd.

It seems to me that the ideal solution would list all the DLLs, 
noting which could not be found, and also giving a warning if a DLL
is not executable.  Perhaps that kind of solution could be achieved by
modifiying ldd using Microsoft's sample code as an example.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple