why while loop works from terminal if ld-2.17.so have no executable permission?

Question

In my previous question, executed "chmod 666 ld-2.17.so" - how can i recover? I asked if I change ld-2.17.so permission to read, how can I recover it back, since it won't allow me to execute anything at all that requires these libraries ?

And I got the answer as follows,

If you have an executable file you can write to, you could copy the contents of ld.so to that file using bash's read:

while IFS= read -d '' -r line; do printf "%s\0" "$line"; done > executable-file < /lib64/ld-2.17.so

I tried it, and it worked. But what I am confused about is why this while loop works if /bin/bash itself requires lib64/ld-2.17.so library, as can be seen as follows,

ldd /bin/bash
    linux-vdso.so.1 =>  (0x00007ffc54dee000)
    libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f6fb9bbe000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f6fb99ba000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f6fb95f6000)
    /lib64/ld-linux-x86-64.so.2 (0x000055ec142f5000)

Can someone please tell me why bash code worked from terminal without the /lib64/ld-2.17.so? Does that also mean that I can also create an empty executable file using bash from terminal even if /lib64/ld-2.17.so has no permissions?

Thank you

Answer 1

while IFS= read -d '' -r line; do 
    printf "%s\0" "$line"
done > executable-file < /lib64/ld-2.17.so

only uses shell built-ins, so it doesn’t need to start new processes. The recovery scenario assumes that you already have a shell running; since it’s already running, its permissions on disk, and those of its libraries, no longer matter.

You wouldn’t be able to start a new shell under these circumstances, but nothing currently running is affected by the changed permissions.

If the file you’re trying to read from has no permissions, this will only work if you’re in a root shell; otherwise the redirection from ld-2.17.so will fail since you can’t read from an unreadable file unless you’re root. (I’m ignoring SELinux etc. here.)