I modified /etc/profile to use a more secure umask for the users (027). For root, I added an umask 022 in .bash_profile. When I run gcc-config, it sources /etc/profile and thus resets the umask. Because of that, the wrappers created don't have execution permission for the other users. I think that the permissions should be automatically sets to either the original wrapper (/usr/lib/gcc-config/wrapper) permissions, or, better I think, the same permissions than the real files (/usr/i686-pc-linux-gnu/gcc-bin/3.2/gcc and the like)
Created attachment 10714 [details, diff] gcc-config-1.3.1-r1.patch
Personally, I think the permissions should be determined by the umask, as you have seen. The problem occurs from gcc-config's disruption of its environment. I am currently rewriting gcc-config, and it no longer sources /etc/profile. This should solve your problem, but I'll also look at the new code to ensure that there are no further issues in this regard. Can you wait for me to fix this in gcc-config-1.4.*?
> Personally, I think the permissions should be determined by the umask, as you > have seen. The problem occurs from gcc-config's disruption of its > environment. The file is create by root so it should not use the normal user's umask. It's fine with if it uses root's umask. > Can you wait for me to fix this in gcc-config-1.4.*? I sure can. I'm not playing much with gcc profiles anyway (only when upgrading).
Why not rather set user umask like: [ "$USER" != "root" ] && umask 027 You will run into problems with you current setup for all non login shells as user root.
If I'm not mistaken, if the shell doesn't read ~/.bash_profile, it won't read /etc/profile either. But it's still a good idea for application sourcing /etc/profile directly (which should actualy source all the other login files also). On the other hand, the config being root specific, it make sense to have it in the root's config file, not the generic one.
Azarah, is this still an issue in gcc-config-1.3.3-r1? The attached patch applies to current gcc-config with some file offsets, so perhaps it's worth looking into?
The point I wanted to make is that a lot of scripts source /etc/profile to get everything setup properly, and setting something critical as umask in root's .bash_profile, will break more things than gcc-config. I really think it should be a 'user side' fix.
Resolving as WONTFIX, as the issue should be done user-side.
I don't understand. The patch just sets the same permission to the wrapper than to the real binary. What's wrong with that? Why allow more restrictive permissions on the wrapper than on the binary itself? It is in my opinion the correct behavior. The fact that it fixes problems when root as its own umask in .bash_profile is just a side effect.
*** Bug 25134 has been marked as a duplicate of this bug. ***
In bug 25134 I was told to post comments here instead of filing a new bug, so: Currently, when emerge'ing gcc-config, the gcc-config ebuild runs gcc-config with the umask of whatever portage inherited from /etc/profile without ensuring that the permissions are setup properly on /usr/bin/{gcc,cpp,cc,etc.} I think that particular behavior is broken, and leads to bugs like bug 25134
Oops, ok, it doesn't run with the umask it inherited from portage, it sources /etc/profile internally. I think the correct behavior is for gcc-config to use the umask it inherited from the user running it, since that is what standard behavior is and what most people would expect. It would also guarantee correct permissions in the case of emerge'ing gcc-config, since portage seems to internally set it's umask to 022.
If not something like the following, than at least adding a warning to the /etc/profile in baselayout not to change root's umask or it will break ones system. --- /usr/portage/sys-devel/gcc-config/files/gcc-config-1.3.3 2003-04-27 22:14:30.000000000 -0400 +++ /home/gatto/gcc-config-1.3.3 2003-11-14 19:51:21.000000000 -0500 @@ -205,7 +205,9 @@ echo "CURRENT=${CC_COMP}" > /etc/env.d/gcc/config + local UMASK=$(umask) source /etc/profile + umask ${UMASK} # These might not be installed, and we want to update the mtime # for ccache and distcc anyhow ...
