/usr/lib/libcpupower.so.0.0.0 is world writable Reproducible: Always Steps to Reproduce: 1. install sys-power/cpupower-3.18 2. ls -la /usr/lib/libcpupower.so.0.0.0 3. Actual Results: A world writable file Expected Results: No world writable file
Can't reproduce that. 1) Please post your `emerge --info' output in a comment. 2) Please attach the entire build log to this bug report.
Created attachment 392630 [details] build.log build.log attached
What filesystem do you use for /var/tmp?
Is this because FEATURES=fakeroot?
vartmpportage on /var/tmp/portage type tmpfs (rw,noatime,size=7600M,nr_inodes=4M)
(In reply to Jeroen Roovers from comment #4) > Is this because FEATURES=fakeroot? I do use fakeroot, yes.
Instaling it using # FEATURES="-fakeroot" emerge -av sys-power/cpupower --nodeps doesn't help.
Created attachment 392632 [details] emerge --info
Added two "dependencies" for information. Is there any progress on this bug?
The files seem to be created 777 in the /work dir. Thus, the "cp" is doing just right. root@marc:~ # ls -lai /var/tmp/portage/sys-power/cpupower-3.18/work/linux-3.18/tools/power/cpupower/ insgesamt 108 105592 drwxrwxr-x 8 root root 320 22. Jan 23:57 ./ 105591 drwxr-xr-x 3 root root 60 22. Jan 23:57 ../ 105593 -rw-rw-r-- 1 root root 506 7. Dez 23:21 .gitignore 104840 -rw-rw-r-- 1 root root 10201 22. Jan 23:57 Makefile 105595 -rw-rw-r-- 1 root root 1517 7. Dez 23:21 README 105596 -rw-rw-r-- 1 root root 446 7. Dez 23:21 ToDo 105597 drwxrwxr-x 2 root root 300 7. Dez 23:21 bench/ 107154 -rwxrwxrwx 1 root root 65512 22. Jan 23:57 cpupower* 105611 drwxrwxr-x 5 root root 100 7. Dez 23:21 debug/ 105623 drwxrwxr-x 2 root root 160 22. Jan 23:57 lib/ 108070 lrwxrwxrwx 1 root root 20 22. Jan 23:57 libcpupower.so -> libcpupower.so.0.0.0* 108074 lrwxrwxrwx 1 root root 20 22. Jan 23:57 libcpupower.so.0 -> libcpupower.so.0.0.0* 106242 -rwxrwxrwx 1 root root 17676 22. Jan 23:57 libcpupower.so.0.0.0* 105628 drwxrwxr-x 2 root root 200 7. Dez 23:21 man/ 105637 drwxrwxr-x 2 root root 240 22. Jan 23:57 po/ 105643 drwxrwxr-x 4 root root 400 22. Jan 23:57 utils/ I have /var/tmp/portage mounted with "(rw,noatime,size=7600M,nr_inodes=4M)" as a RAM disk.
I've come somewhat further: It happens when using FEATURES with ccache _and_ CCACHE_UMASK=000: ccache disabled: root@marc:~ # ls /usr/lib/libcpupower.so* 4719118 lrwxrwxrwx 1 root root 20 28. Jan 06:47 /usr/lib/libcpupower.so -> libcpupower.so.0.0.0* 4722548 lrwxrwxrwx 1 root root 20 28. Jan 06:47 /usr/lib/libcpupower.so.0 -> libcpupower.so.0.0.0* 4737282 -rwxr-xr-x 1 root root 17676 28. Jan 06:47 /usr/lib/libcpupower.so.0.0.0* ccache w/o CCACHE_UMASK: root@marc:~ # ls /usr/lib/libcpupower.so* 4719118 lrwxrwxrwx 1 root root 20 28. Jan 06:44 /usr/lib/libcpupower.so -> libcpupower.so.0.0.0* 4722548 lrwxrwxrwx 1 root root 20 28. Jan 06:44 /usr/lib/libcpupower.so.0 -> libcpupower.so.0.0.0* 4735418 -rwxrwxr-x 1 root root 17676 28. Jan 06:43 /usr/lib/libcpupower.so.0.0.0* ccache w/ CCACHE_UMASK=000: root@marc:~ # ls /usr/lib/libcpupower.so* 4719118 lrwxrwxrwx 1 root root 20 28. Jan 06:46 /usr/lib/libcpupower.so -> libcpupower.so.0.0.0* 4722548 lrwxrwxrwx 1 root root 20 28. Jan 06:46 /usr/lib/libcpupower.so.0 -> libcpupower.so.0.0.0* 4738009 -rwxrwxrwx 1 root root 17676 28. Jan 06:46 /usr/lib/libcpupower.so.0.0.0* My ccache version is 3.1.9-r4, last stable. I had issues with 3.1.10+.
*** Bug 536970 has been marked as a duplicate of this bug. ***
*** Bug 537374 has been marked as a duplicate of this bug. ***
Hi everybody, any news on this one? Anything I could do?
I'm not sure this is even a bug.
I setup ccache this way as I wanted (and want to) share the cache accross multiple user (portage, myself, my wife). According to the docs CCACHE_UMASK is used for this. If I do not set it up like this, I get compile errors (possibly due to read-only files in the cache). How can I setup a shared cache and circumvent the behavior by another mechanism?
OK, first of all (kinda ironic): thanks for the support. I fixed this myself now. What I did (for reference) was: Having a lib installed with o+w I tried setting stuff up for this lib to get fixed. 4757539 -rwxrwxrwx 1 root root 1564232 8. Feb 15:01 /usr/lib/libvpx.so.1.3.0* 1.) I added root, portage, marc, stefanie (the users who use ccache) to the 'ccache' group. 2.) I cleared the ccache using ccache -C 3.) I updated the /home/ccache file store using - find /home/ccache/ -type d | xargs chgrp ccache - find /home/ccache/ -type d | xargs chmod g+s 4.) Set CCACHE_UMASK in make.conf to 0002 5.) Rebuild libvpx 6.) Check the results: 4735742 -rwxrwxr-x 1 root root 1564232 12. Feb 10:23 /usr/lib/libvpx.so.1.3.0* 7.) Check some example cache contents: 11272211 drwxrwsrwx 2 root ccache 425984 12. Feb 10:23 ./ 11272194 drwxrwsrwx 18 root ccache 4096 12. Feb 10:23 ../ 11272264 -rw-rw-r-- 1 root ccache 16052 12. Feb 10:23 2aeff80e2a3cf06a6c703fa535568d-116590.o 11272257 -rw-rw-r-- 1 root ccache 31416 12. Feb 10:23 4dbde70804a6f49ef7c635a57562d0-71545.o 11272249 -rw-rw-r-- 1 root ccache 54400 12. Feb 10:23 30cc5e2d1a12fc858c0999607c5c67-335562.o 11272265 -rw-rw-r-- 1 root ccache 1638 12. Feb 10:23 857c761aff9cf083996d87a9148ff6-159601.manifest 11272258 -rw-rw-r-- 1 root ccache 721 12. Feb 10:23 a01227652760261a00dbcfd34b9137-21230.manifest
I think using CCACHE_UMASK=022 is even better. This also removes group-writable. If the file is in cache, it does not need to be written again anyways and is just used. Thus there is no need for files in the cache to stay g+w to be rewritten again. 4729995 -rwxr-xr-x 1 root root 1564232 12. Feb 10:42 /usr/lib/libvpx.so.1.3.0*
