On Fri, Jul 19, 2019 at 11:36:53PM +0200, Mark Wielaard wrote: > On Sat, Jul 20, 2019 at 12:23:08AM +0300, Dmitry V. Levin wrote: > > On Fri, Jul 19, 2019 at 11:00:49PM +0200, Florian Weimer wrote: > > > * Dmitry V. Levin: > > > > > > >> So, I don't think the code is wrong. We might want to tweak the comment > > > >> a bit though, to make it less definitive? > > > > > > > > What I'm saying is that has_soname is just a hint which is probably even > > > > less reliable than has_program_interpreter. > > > > > > If I recall correctly, I added the soname check to classify > > > /lib64/libc.so.6 as a library, not an executable. So it didn't come > > > completely out of nowhere. > > > > Well, /lib64/libc.so.6 is not just a library, it's also a valid executable. > > > > If the ELF type is ET_DYN and the object is not marked as DF_1_PIE, > > could we come up with a more reliable heuristics than DT_SONAME and > > PT_INTERP? > > Why do you feel it is unreliable? Do you have any examples of files > misidentified?
No, I don't have such examples because most (if not all) ET_DYN non-DF_1_PIE objects we have nowadays are actually libraries regardless of their DT_SONAME or PT_INTERP. What actually disqualifies these objects from being libraries, besides missing PT_DYNAMIC? The only reason why I feel uncomfortable to rely on this has_soname check is that DT_SONAME is so easily added unnoticed by mistake. btw, I think it would be appropriate to move the has_dynamic check before the first check in is_shared that returns true. -- ldv
signature.asc
Description: PGP signature
