I don't know if this problem is home-made by Gentoo or an upsteam Gnome problem: When a Gnome session is started by GDM, the user's .bashrc (or .bash_profile) is not sourced, at least not before starting important programs. Why I noticed and why this is a security problem: I have several security-related settings in my .bashrc: Most important and absolutely required (by company regulations) is an umask of 077. Moreover, stricter ulimits are set, the PATH is modified such that specially prepared executables are found before the standard executables of the same name (firefox is jailed), and so on. However, I noticed that all gnome background processes and more important all programs I start from the panel or the menu do *not* run with the settings in my .bashrc. Most impostant, they have no UMASK set and create files which are group/world readable, sometimes even group-writeable. I fixed that by creating /etc/X11/xinit/xinitrc.d/05-bashrc saying #!/bin/bash # source the user's .bashrc if [ -f "$HOME/.bashrc" ] then . "${HOME}/.bashrc" fi I don't know if this is the correct / best way to do it, but somehow the .bashrc should be sourced before starting the background processes and the panel.
This is not a gnome nor an xinit problem, this is a local setup issue (not even distro specific). First off, we can't source random files with the assurance it'll work on any computer out there. Then if you really need to do that, you certainly should not make your X init scripts load your bashrc but rather rely on bash_profile. For example, keychain script provided by gdm-2.20.10 in tree does that. Closing invalid.
For the record, GDM allows you to have a .xprofile file which should be sourced before pretty much everything else. Give it a try. Thanks
Well, what is done now by GDM in 49-keychain is even more random, so don't argument with not doing random things: * It only tries .bash_profile (for bash users), not .profile (for ksh) or .login (for csh). It should perhaps test all or none of them. * It only does that if keychains are in use. Reading or not reading the profiles can make a *big* difference, and there is absolutely no reason why this big difference should depend on keychains. So, if you read profiles in case of keychains, you should read them always (or never, to be consistent and - in your words - "non-random"). And I don't insist on .bashrc, .bash_profile is fine for me, too (it sources my .bashrc anyway).
Klaus, you seem to have requirements that go beyond the use-cases we usually cater for. Nothing prevents you from doing your own changes on your own systems. So unless you find a _bug_, your issue is "just" a user-configuration issue. Thanks
Also you seemed to miss in my comment that keychain is a example of a really specific use case. Before being split where it currently is located, gdm would simply fail to open your session if the default shell was something else than bash and your bash_profile had bashism. The current way makes it specify clearly it is to be executed by bash and works only with bash in mind. You are free to modify it to suit your case of submit another bug report to make it more generic. In any way, the point was just to demonstrate how what you want could be done. Remi also pointed a really good alternative which is to use .xprofile which is what packages like scim advise you to use.
