This is possible if you ldconfig a folder with libraries that requires glibc 2.5 during runtime. However, you system is using only glibc 2.3. At your next system startup, your system will try to load the shared object, but, it will fail and denied your log in.
To recover from this, you could do the following (assuming that you are using CentOS)
1. Boot up your system with your Linux installation disc
2. Go into Rescue mode. Simply following the on screen instruction given to load rescue mode.
3. When you are in Rescue mode, you are able to access your system. Usually, your original drive will be mounted in /mnt/sysimage/
4. Create a ld.so.conf file at /
5. Then, cd /mnt/sysimage/
6. Then, find your corrupted ld linkage. Using libtermcap.so as example, you can perform find /mnt/sysimage -name libtermcap.* . This command will find the located of this shared object.
7. Normally, system libraries are located at lib folder and I will use this as example.
8. Then, cd /mnt/sysimage/lib
9. Perform ldconfig
10. Please note that ldconfig kind of hardcode the ld.so.conf to / and that is the reason we create a ld.so.conf file at / in point 4
11. Go to / and perform cp ld* /mnt/sysimage/etc/
12. This will replace the corrupted ld.conf.so and ld.conf.cache.
13. Restart your system.