Description of problem: As root, I like put, . in PATH and if I go to /etc/cron.daily and run rpm I send machine down! Version-Release number of selected component (if applicable): all Steps to Reproduce: 1. export PATH=.:$PATH 2. cd /etc/cron.daily 3. rpm Additional info: this send machine down 2 ways to resolve this issue mv rpm rpm.cron or edit rpm and change rpm to /bin/rpm the problem is have 2 rpm files and one call rpm again this could be avoid
Having '.' in PATH as root is heavily discouraged, for reasons such as the above (consider /tmp where all users can write for example)
well the problem is not the . in PATH, the problem is having 2 executables with the same name. Try put in PATH /etc/cron.daily/ before /usr/bin and see what happens when run /etc/cron.daily/rpm . This have 2 problems /etc/cron.daily/rpm call rpm without PATH so bash have to looking in the path for a rpm which could be himself. Do you understand what is my point ?
The root cause of your problem is having '.' in a path causing the script to be in your PATH. I as a malicous user can create a +s shell add a new uid 0 user or any number of things in /tmp/rpm or /tmp/anylikelycommand if you have . in PATH as root and are not careful. /etc/cron.daily should never be in any sane PATH so normal users don't care.
Well , I give up , this discussion don't go anywhere, but keep in mind, for me, the problem is having two executables files called rpm one /bin/rpm and other /etc/cron.daily/rpm and /etc/cron.daily/rpm call rpm without any PATH. if /etc/cron.daily/rpm call /bin/rpm, I won't have this problem.
The problem is not that the /etc/cron.daily/rpm script is named rpm. The problem is that it doesn't give an absolute path to /bin/rpm when invoking it, nor does it reset the PATH variable to a well-defined secure value. This is indeed a potential risk. This should be reopened.
rpm-4.4.2-11