Summary: | ldconfig - auxiliary cache does not work properly with -r option | ||
---|---|---|---|
Product: | glibc | Reporter: | Vasily Gurevich <vas.gurevich> |
Component: | libc | Assignee: | Ulrich Drepper <drepper.fsp> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | anssi.hannula, glibc-bugs |
Priority: | P2 | Flags: | fweimer:
security-
|
Version: | 2.11 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Attachments: | proposed patch |
Description
Vasily Gurevich
2010-01-08 18:38:22 UTC
I agree with the aux cache file setting (although I used a simpler patch). You will have to explain the second part. Describe the setup you think creates a problem. I use maemo SDK+. It does not use chroot. I launch ldconfig -r /our_new_root. It finds link to /lib/ourlib inside /our_new_root and tries to stat /lib/ourlib. But we specify -r /our_new_root. So it shall stat /our_new_root/lib/ourlib according to -r options. My patch provides this functionality. Thank you. (In reply to comment #2) > I use maemo SDK+. It does not use chroot. I launch ldconfig -r /our_new_root. It > finds link to /lib/ourlib inside /our_new_root and tries to stat /lib/ourlib. Explain exactly where the link is located etc. I need to be able to reproduce this here. #pwd /lib #ls -la somelib somelib.ln -> somelib #pwd ~/our_new_root/lib #ls -la somelib somelib.ln -> somelib ldconfig searchs it in aux cache (search_aux_cache), does not find, tries to add (add_to_aux_cache) and aborts when tries to insert. Please, ask me if it is not enough. Thank you. (In reply to comment #4) > Please, ask me if it is not enough. Thank you. It isn't enough. First, files named somelib are ignored because they don't look like libraries. I asked for the exact situation, not some general idea. Second, even if I'm using a real library with its real name and then a link I see no accesses outside the chroot: I copied libc.so in a chroot tree and added libc.so.6 as a symlink. The only accesses to libc.so of ldconfig -r $PWD/testroot are: lstat("$PWD/testroot/lib64/libc.so", {st_mode=S_IFREG|0775, st_size=9166760, ...}) = 0 open("$PWD/testroot/lib64/libc.so", O_RDONLY) = 4 stat("$PWD/testroot/lib64/libc.so.6", {st_mode=S_IFREG|0775, st_size=9166760, ...}) = 0 lstat("$PWD/testroot/lib64/libc.so.6", {st_mode=S_IFLNK|0777, st_size=7, ...}) = 0 readlink("$PWD/testroot/lib64/libc.so.6", "libc.so", 4096) = 7 lstat("$PWD/testroot/lib64/libc.so", {st_mode=S_IFREG|0775, st_size=9166760, ...}) = 0 lstat("$PWD/testroot/lib64/libc.so.6", {st_mode=S_IFLNK|0777, st_size=7, ...}) = 0 lstat("$PWD/testroot/lib64/libc.so.6", {st_mode=S_IFLNK|0777, st_size=7, ...}) = 0 readlink("$PWD/testroot/lib64/libc.so.6", "libc.so", 4096) = 7 lstat("$PWD/testroot/lib64/libc.so", {st_mode=S_IFREG|0775, st_size=9166760, ...}) = 0 stat("$PWD/testroot/lib64/libc.so", {st_mode=S_IFREG|0775, st_size=9166760, ...}) = 0 lstat("$PWD/testroot/lib64/libc.so", {st_mode=S_IFREG|0775, st_size=9166760, ...}) = 0 write(3, "libc.so.6\0/lib64/libc.so.6\0", 27) = 27 I have of course replace the real path with $PWD in the output. But as you can see there is no access outside the chroot. Either provide _exact_ instructions for how to show the problem or close the bug. And make sure you're using current sources. I am sorry. I built glibc-2.11.1 on top of my ubuntu jaunty. There are minimum settings: # pwd /home/user/testroot # find . ./lib ./lib/libBrokenLocale.so.1 ./lib/libBrokenLocale-2.8.so ./etc ./etc/ld.so.conf ./var ./var/cache ./usr ./usr/lib ./usr/lib/libBrokenLocale.so # pwd /home/user/testroot/lib # ls -l -rw-r--r-- 1 user user 5484 2010-02-23 15:55 libBrokenLocale-2.8.so lrwxrwxrwx 1 user user 22 2010-04-12 20:27 libBrokenLocale.so.1 -> libBrokenLocale-2.8.so # pwd /home/user/testroot/usr/lib # ls -l lrwxrwxrwx 1 user user 25 2010-04-12 20:26 libBrokenLocale.so -> /lib/libBrokenLocale.so.1 And when I launch ldconfig it is aborted: # ./ldconfig -r /home/user/testroot/ Aborted It shall be enough. It was three months ago, I am sorry again. OK, I fixed it now. The patch differes from yours. Thanks a lot. Could you provide version number where can I verify it, please. Thank you. Version 2.12 should have the fix, as well as 2.11.2. I checked glibc-2.11.2. It is still aborted. Will continue soon. Many thanks. Excuse me. It works fine. It was my mistake. Thanks a lot. Verified. Unfortunately, the aux_cache change introduced a bug - normally, ldconfig -r never cares if the auxiliary cache is not available and that is not a fatal problem, however this is not the case in case of ldconfig -r when executed as non-root. In that case, ldconfig -r fails hard unless var/cache/ldconfig/ exists within the chroot. Patch to follow. Created attachment 4825 [details]
proposed patch
This has long since been fixed. |