compiled linux library (.so) is executable

[Чебурашка]

Hello,
in debian (maybe someone might want to check in other linuxes) why when compiling either under lazaruz, or lazbuild, or even doing fpc -s + ppas.sh, if the object to be produced is a .so, it results 755? Normally libraries are 644 (at least in debian). Ok there are some that can be directly executed, maybe is it for this reason?

[marcov]

It's the linker that creates the file ?

Maybe it is the dlltool that does the installing of the library that sets the permissions ?

[Чебурашка]

It's the linker that creates the file ?

Maybe it is the dlltool that does the installing of the library that sets the permissions ?

I found that "gcc -c" makes the output file non executable, so it is possible to have the final result not executable (despite default is yes).
I will try on a alpine linux to see how fpc+lazarus do.
I suspect it's a config of the deb.
I will tell after.

[Fred vS]

Hello.

Maybe it is a executable compiled with 'hardening' and became a "executable library":
https://wiki.freepascal.org/hardening

[MarkMLl]

Looking at Debian 12 ("Bookworm") because of something in another thread, I note

Code: Text  [Select][+][-]

1. -rw-r--r-- 1 root root      283 Apr 10 09:35 libc.so
2. -rwxr-xr-x 1 root root  1922136 Apr 10 09:35 libc.so.6
3.  

where libc.so is actually a linker script.

So I don't know what's really going on, but I think we need to be prepared for some traditional unix weirdness.

MarkMLl

[Чебурашка]

So I don't know what's really going on, but I think we need to be prepared for some traditional unix weirdness.

I found same on deb 11, also I tried to run it, here's a few nice output lines:

Code: Pascal  [Select][+][-]

1. user@debian-11:~$ /lib/x86_64-linux-gnu/libc-2.31.so
2. GNU C Library (Debian GLIBC 2.31-13+deb11u5) stable release version 2.31.
3. Copyright (C) 2020 Free Software Foundation, Inc.
4. This is free software; see the source for copying conditions.
5. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
6. PARTICULAR PURPOSE.
7. Compiled by GNU CC version 10.2.1 20210110.
8. libc ABIs: UNIQUE IFUNC ABSOLUTE
9. For bug reporting instructions, please see:
10. <http://www.debian.org/Bugs/>.
11.  

While libm is not executable:

Code: Pascal  [Select][+][-]

1. user@debian-11:~$ ls /lib/x86_64-linux-gnu/libm.* -l
2. -rw-r--r-- 1 root root 132 Oct 14  2022 /lib/x86_64-linux-gnu/libm.a
3. -rw-r--r-- 1 root root 140 Oct 14  2022 /lib/x86_64-linux-gnu/libm.so
4. lrwxrwxrwx 1 root root  12 Oct 14  2022 /lib/x86_64-linux-gnu/libm.so.6 -> libm-2.31.so
5.  
6. user@debian-11:~$ ls /lib/x86_64-linux-gnu/libm-2.31.so -l
7. -rw-r--r-- 1 root root 1321344 Oct 14  2022 /lib/x86_64-linux-gnu/libm-2.31.so
8.  

I would bet there is a logic on this, debian is very careful to these things.

[MarkMLl]

I would bet there is a logic on this, debian is very careful to these things.

I have an /extremely/ vague recollection that libc is executable specifically so that it can report the version of the core system-level libraries.

Code: Text  [Select][+][-]

1. # find /lib /usr/lib -type f -name '*so.*' -ls 2> /dev/null | grep rwx | less
2.  12846584    208 -rwxr-xr-x   1 root     root        210968 Apr 10 09:35 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
3.  12846588   1880 -rwxr-xr-x   1 root     root       1922136 Apr 10 09:35 /usr/lib/x86_64-linux-gnu/libc.so.6
4.  
5. # find /lib /usr/lib -type f -name '*so' -ls 2> /dev/null | grep rwx | less
6.  13388759     40 -rwxr-xr-x   1 root     root        39152 Jan 22 05:37 /usr/lib/grass82/bin/v.net.iso
7.  12848415     76 -rwxr-xr-x   1 root     root        74688 Feb 12 22:57 /usr/lib/klibc-XX6cASCB7KZyJWpIJW79y94XHBY.so
8.  

However when I do a brute-force search over the entire system I find a whole lot of stuff that I've either compiled locally (e.g. Mozilla Kompozer) or installed into a Docker container (various microcontroller and FPGA stuff) which have most if not all of their .so libraries marked executable. That obviously boils down either to multiple projects' build methodology, or to a default option in ld (or possibly install or equivalent which handled the final placement).

MarkMLl

[Чебурашка]

Hello.

Maybe it is a executable compiled with 'hardening' and became a "executable library":
https://wiki.freepascal.org/hardening

These are the options in project (omitting paths to unit+inc)

Code: Pascal  [Select][+][-]

1. /usr/bin/fpc
2. -MObjFPC
3. -Scghi
4. -Cg
5. -g
6. -gl
7. -gh
8. -gt
9. -l
10. -vewnhibq
11. -vm6058,3124,3123
12. [ ... ]
13.  

so seems is not this case.

[Fred vS]

May I ask what result you get if you do on console?:

Code: Pascal  [Select][+][-]

1. $> file yourbinary

[Чебурашка]

May I ask what result you get if you do on console?:

Code: Pascal  [Select][+][-]

1. $> file yourbinary

Sure (just renamed lib to libxyz):

Code: Pascal  [Select][+][-]

1. [user@deb-9]# file libxyz-i386-linux.so
2. libxyz-i386-linux.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
3.  

[Fred vS]

Code: Pascal  [Select][+][-]

1. [user@deb-9]# file libxyz-i386-linux.so
2. libxyz-i386-linux.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
3.  

Indeed, it is not hardened ( should be "LSB pie").
So, sorry, I dont know why your library is set as 755.

[Raskaton]

1. Check Project options "Miscellaneous" -> "Project is runnable"
https://wiki.freepascal.org/IDE_Window:_Project_Options#Project_is_runnable

2. May be, if in IDE Compiler Options disable flag "Apply conventions" and set target as "project.so" affect this too.