Description of problem: mga6 official bash is executing ~/.profile even though ~/.bash_profile exists upon login. Invocation 4'th paragraph of man bash indicates ~/.bash_login and ~/.profile will not be executed if ~/.bash_profile exists. When bash is invoked as an interactive login shell, or as a non-inter‐ active shell with the --login option, it first reads and executes com‐ mands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. Seems like an easy way for malware to invoke its self without the user knowing ~/.profile is being executed during login. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. echo "touch dot_profile.ran" >> ~/.profile 2. chmod +r ~/.profile 3. echo "touch dot_bash_login.ran " >> ~/.bash_login 4. chmod +x ~/.bash_login 5. log out/in 6. click up a terminal 7. ls -al *ran
Assigning to the registered maintainer.
CC: (none) => marja11Assignee: bugsquad => shlomif
and what would prevent the same malware to invoke itself from .bash_profile ? :)
CC: (none) => tmb
Everything seems fine here on mga7, in a new user - ~/.profile does not get executed. I also agree with tmb's reasoning. Can I close this as wontfix?
(In reply to Shlomi Fish from comment #3) > I also agree with tmb's reasoning. Can I close this as wontfix? I can also see tmb's reasoning, not everyone knows about ~/.profile and ~/.bash_login, but if they were looking through /etc/profile, /etc/bashrc, ~/.bash_profile they will not see where the malware was launched. I mentioned it as just an example and am not here to defend other ways to insert malware. The bug is that bash is not following the defined Invocation rules. > Everything seems fine here on mga7, in a new user - ~/.profile does not get > executed. Well, it does on my mga6 upgraded to Cauldron. No idea if it matters, running $ cat /etc/sysconfig/desktop DISPLAYMANAGER=LIGHTDM $ echo $XDG_CURRENT_DESKTOP XFCE
It comes from lightdm's /etc/lightdm/Xsession. I've added the sourcing calls there [1], but can't remember what was the exact problem. I can drop the wrapper scriptlet from Cauldron and see if it causes issues. [1] http://svnweb.mageia.org/packages?view=revision&revision=263830
CC: (none) => jani.valimaa
(In reply to Jani Välimaa from comment #5) > It comes from lightdm's /etc/lightdm/Xsession. I've added the sourcing calls > there [1], but can't remember what was the exact problem. Heheh, always helps to add reason for change in the change log. :) If not a comment above the code. Work around: Prevent *profile calls. Not noticing any impact in mga6 or mga7 after reboot. ]$ cat /etc/lightdm/Xsession #!/bin/bash -login if [ 1 -eq 0 ] ; then [ -f /etc/profile ] && . /etc/profile [ -f ~/.profile ] && . ~/.profile fi exec /etc/X11/Xsession $* # Xsession ends here
Source RPM: bash-4.3-48.3.mga6.src.rpm => lightdm-1.18.3-3.mga6.src.rpm
latest lightdm-1.25.1-4.mga7 release removes /etc/lightdm/Xsession and prevents gui login. Workaround. created or restore /etc/lightdm/Xsession
(In reply to Bit Twister from comment #7) > latest lightdm-1.25.1-4.mga7 release removes /etc/lightdm/Xsession and > prevents gui login. > > Workaround. > > created or restore /etc/lightdm/Xsession I can't reproduce the login issue with -4.mga7. /etc/lightdm/Xsession was removed, but it's not used in anywhere. Lightdm config was switched to use Xsession wrapper from xinitrc. $ grep -r Xsession /etc/lightdm/ /etc/lightdm/lightdm.conf.d/50-mageia.conf:session-wrapper=/usr/share/X11/xdm/Xsession # grep -r Xsession /var/log/lightdm/lightdm.log [+483.69s] DEBUG: Session pid=976: Running command /usr/share/X11/xdm/Xsession startxfce4
(In reply to Jani Välimaa from comment #8) > > I can't reproduce the login issue with -4.mga7. > I do not know what is going on. I tried 3 login attempts after the update and during DE init I was sent back to log login screen. scp'ed a copy from mga6, next log in completed. just now wiped it out, cleared all logs and rebooted and login works.
CC: (none) => curtis_mageia
closing bug
Status: NEW => RESOLVEDResolution: (none) => FIXED