Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 19395 - gcc-config-1.3.1-r1 doesn't set the permissions
Summary: gcc-config-1.3.1-r1 doesn't set the permissions
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Please assign to toolchain
URL:
Whiteboard:
Keywords:
: 25134 (view as bug list)
Depends on: 18933
Blocks:
  Show dependency tree
 
Reported: 2003-04-15 20:32 UTC by Nahor
Modified: 2003-11-14 17:02 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
gcc-config-1.3.1-r1.patch (gcc-config-1.3.1-r1.patch,1.10 KB, patch)
2003-04-15 21:07 UTC, Nahor
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nahor 2003-04-15 20:32:45 UTC
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)
Comment 1 Nahor 2003-04-15 21:07:25 UTC
Created attachment 10714 [details, diff]
gcc-config-1.3.1-r1.patch
Comment 2 Zach Welch (RETIRED) gentoo-dev 2003-04-16 14:36:14 UTC
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.*?
Comment 3 Nahor 2003-04-16 14:53:17 UTC
> 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).
Comment 4 Martin Schlemmer (RETIRED) gentoo-dev 2003-04-21 16:06:26 UTC
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.
Comment 5 Nahor 2003-04-21 16:30:25 UTC
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.
Comment 6 Joshua Kinard gentoo-dev 2003-10-01 21:57:19 UTC
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?
Comment 7 Martin Schlemmer (RETIRED) gentoo-dev 2003-10-04 21:36:15 UTC
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.
Comment 8 Joshua Kinard gentoo-dev 2003-10-04 21:48:29 UTC
Resolving as WONTFIX, as the issue should be done user-side.
Comment 9 Nahor 2003-10-05 12:11:19 UTC
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.
Comment 10 Donnie Berkholz (RETIRED) gentoo-dev 2003-11-14 14:24:34 UTC
*** Bug 25134 has been marked as a duplicate of this bug. ***
Comment 11 gatto 2003-11-14 15:01:26 UTC
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
Comment 12 gatto 2003-11-14 16:40:33 UTC
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.
Comment 13 gatto 2003-11-14 17:02:05 UTC
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 ...