When gcc starts it looks for a 'specs' file from the current working directory, which is totally wrong. It should use an absolute path instead and not look from cwd at all. Normally it can't find the specs from cwd and only after that it uses an absolute path to find the correct specs file. Reproducible: Always Steps to Reproduce: strace gcc 2>&1 | grep specs Actual Results: On my system it looks for specs in this order: access("./i686-pc-linux-gnu/3.2.3/specs", R_OK) = -1 ENOENT access("./specs", R_OK) = -1 ENOENT access("/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/specs", R_OK) = 0 Expected Results: It shouldn't have looked in ./ at all. This behavior prevented me from compiling avr-gcc because the system gcc found avr-gcc's specs file (./specs in the objdir) and got really confused. I've tried gcc 3.3.2 and 3.2.3-r3 and both of them have the same problem. I also got a confirmation from another Gentoo user that his gcc behaves the same, so the problem is probably not specific to my Gentoo installation.
the question is if that is a security problem, a bug and/or a feature. People may consider it a feature when they do not have write access to the specs on a developer machina far far away and want to run and write explicit compiling procedures implementing own specs files. People like you compiling their own gcc versions may find it a buggy hassle and want it to be generalized not to happen any more. It becomes a security issue when you trust the directories in which you are compiling, for example compiling applications as root in directories where untrusted users have access to, for example a temporary directory. But normally you do not do that and own all the rights on the directories you are compiling applications for the system. To give you an impression what could be done is that the gcc wrapper in gcc-config could prevent that for Gentoo users, explicitly stating this specs file via commandline in the wrapper. The question is again, if this is wanted by all users. you may always override your CC environment var with a value of "gcc -wanted-specs-file-and-so-on" to be satisfied. The overhead of doing it in the wrapper would impose a significant burden of the overal complexity in the toolchain already present and leading to confusion sometimes. So, i think following your advice and suppressing this behaviour would limit the choices of other users and thus favouring your personal experiences only. I would like to collect the opinions on peer developers on this issue and let the community decide about this possible change. Thank you, Alex
This does not seem to be the case anymore with gcc-3.3.3 solar@simple solar $ strace gcc 2>&1 | grep specs access("/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/specs", R_OK) = 0 open("/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/specs", O_RDONLY) = 3 stat64("/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/specs", {st_mode=S_IFREG|0644, st_size=5282, ...}) = 0 access("/usr/lib/gcc-lib/i686-pc-linux-gnu/specs", R_OK) = -1 ENOENT (No such file or directory)
seems this problem has been solved in recent gcc versions anyway, i mark it WONTFIX because i do not think it to be a "security" issue for USERS using their OWN specs files in $HOME :-)))
