illumos gate

Currently if you run ldd(1) on a shared object which lacks executable permission, you'll see a message like so:

; ldd libtest.so
warning: ldd: libtest.so: is not executable
    libc.so.1 =>     /lib/64/libc.so.1
    libm.so.2 =>     /lib/64/libm.so.2

This warning has no value, there's no reason for a shared object to be executable. The code says:

     /*
      * Check that the file is executable.  Dynamic executables must be
     * executable to be exec'ed.  Shared objects need not be executable to
     * be mapped with a dynamic executable, however, by convention they're
     * supposed to be executable.
      */

Which is a sort of backhanded way of saying "we've always done it". No record can be found of why we have always done it, except for a possible clue that during the initial implementation of mmap(2) with or prior to dynamic linking in SunOS 4, it was considered that perhaps it should be an error to request PROT_EXEC on a file for which you lack execute permission (as with read, or write).

The comment as it exists in uts/common/os/grow.c is:

    /*
     * XXX - Do we also adjust maxprot based on protections
     * of the vnode?  E.g. if no execute permission is given
     * on the vnode for the current user, maxprot probably
     * should disallow PROT_EXEC also?  This is different
     * from the write access as this would be a per vnode
     * test as opposed to a per fd test for writability.
     */

and all signs suggest it has existed since time immemorial.

Given that shared objects being executable is, at present, merely a convention of software delivery. ldd(1) is very much the wrong place to attempt to enforce it.