This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: dll libraries marked for random execution?

On 10 July 2007 20:04, Linda Walsh wrote:

> Pardon me, but I have some questions about libraries under
> cygwin if anyone knows... If there's a doc somewhere that
> answers these questions, a pointer to it would be appreciated.

  Umm, this is all standard stuff but is probably not as well documented as it should be.
> Are all dll libraries supposed to be invocable as executables?

  DLLs and libraries are two entirely different things, connected only by the fact that some static libraries can stand as proxies for the dynamically linked functions of a DLL.  A dll should always be marked as executable, since it contains executable code, but 'invocable' would imply you could meaningfully run it from the command line, which you can't because it's just a library, not an entire program.

> What about libraries with ".a" extensions?  I looked on my SuSE
> linux system and none of the ".a" files are marked executable
> though most of the ".so" files are marked executable.

  Right, you're starting to get confused here.  A ".so" on linux is the same as a ".dll" on windows: it's a dynamically loaded library that gets linked into the application at runtime.  A ".a" file is the same on both: it's a static library that gets linked into the application at the end of the compile.  Files ending ".so" and ".dll" need to be executable because they contain actual live runnable code.  Files ending ".a" are library archives containing multiple snippets of code that can't be run directly because they're only partially-linked and partially-relocatable, like a ".o" file rather than a ".exe".

> If something is not supposed to be an executable, wouldn't it be
> better administrative practice (if not better security practice)
> to mark it as non-executable?

  Pretty unimportant.  If it's not supposed to be an executable, the chances of it containing anything that resembles executable instructions are infinitesimal.  If anything did 

> Isn't ".so" used for sharable libraries and ".a" is used to bind
> the routines into the resultant binary?

  No, that's more like how ".dll" and ".dll.a" work on windows.  On linux, you link against the ".so" if you want the code to be dynamically loaded at runtime, or against the ".a" if you want the code to be statically linked right into your executable for all time at the end of compilation.

> I was under the impression that usually ".dll" files were shared
> under NT, but all the libraries in "/usr/lib" and "/lib" are marked
> ".a".  

  Try looking in /usr/bin, that's where the ".dll" files live.

> Many seem to come in pairs: <libname>.dll.a and <libname>.a
> but if they end with ".a" does that imply they are linked into the
> final binary (not shared)?

  Yes, that's what a static link library is.  In the case of the ".dll.a" files, the static link library doesn't contain the actual code for the functions, it contains wrappers/stubs that call out to the (dynamically-loaded) DLL at runtime.  In a standard ".a" file, the library contains the actual code that implemnents the functions.

> I'm under the impression that certain files with names of the form
> cyg<lib>.dll, in /windows/system32, are sharable.  

  Yes, they are standard windows DLLs.

> But it seems like
> most (all?) of the "standard" (non cygwin specific) libraries have
> the ".a" extension.

  Yes, as mentioned before they contain stubs that link to the actual dll itself.  The reason for this is that it speeds up load times: if there are a thousand calls in the program to DllWhateverFunc, that's a thousand call sites that need to have the correct address of DllWhateverFunc inserted at runtime when the DLL is loaded and the address becomes known.  Instead, you link against the ".dll.a", which is called an "import library".  It will contain an "import stub" for DllWhateverFunc, that simply consists of a jump to the dll's code.  Then, all the thousand callsites are statically linked at compile time to point to the equivalent function "_imp__DllWhateverFunc" brought in from the library, and when the app is actually loaded, only one jump has to be corrected, the one in _imp__DllWhateverFunc, instead of all thousand separate jumps.  Hey presto, much faster load times!

> If non-cygwin support libraries are all unsharable with ".a"
> extensions does that imply there "could" be ".so" files to enable
> the libraries being shared?

  The code in ".a" files is /always/ statically linked, not shareable; it's just that /some/ of the code in /some/ ".a" files, specifically those which are import libraries, contains references out to shared code in dlls, whereas most of the code in most normal ".a" libraries is just plain old code that you link right into your application at compiletime.

> I'd like to get rid of the "executable" bit being set on files that
> are not really executable.  Besides being bad practice, it also
> creates problems when looking for completion values in the shell.  Seem
> to remember some other issues related to dll's being marked as
> executable, but don't recall what they were off-hand...

  Can't think of any myself.  The bogus completions problem is a bit of an inconvenience, but I doubt it's a security issue.  

  The issue you're probably trying to remember is that a dll *must* be marked executable, or it can't be loaded when you start the app that links against it.  Note that this is in terms of the windoze ACLs, not just the cygwin unix perms.

Can't think of a witty .sigline today....

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]