4 ms·
> This is similar to the problems seen when the dot folder is not included in the more familiar PATH variable. Is this implying that you should put `.` on PATH
by ivanbakel 7y ago
> This is similar to the problems seen when the dot folder is not included in the more familiar PATH variable.
Is this implying that you should put `.` on PATH? I've always heard that to be a security problem.
What's interesting is that so many of these variables are incredibly tersely named. What's the reasoning behind not using a full name for them to make Bash actually readable? Surely not the minor performance scrape?
- johannes1234321 7y agoYes, with `.` in the PATH you have potential security issues: If your working directory happens to be world-writable (i.e. while doing cleanup in /tmp) an attacker could put evil replacements into your PATH. "cd /tmp; sudo rm some_file" might execute /tmp/sudo and do really evil stuff. Sure, on an otherwise 100% secure system accessed only by trusted users there is no problem, but not having . in PATH is a trivial mitigation.
- tetha 7y ago> Sure, on an otherwise 100% secure system accessed only by trusted users there is no problem, but not having . in PATH is a trivial mitigation. All systems are secure and sufficiently hardened until a botnet demonstrates otherwise, aren't they? And a botnet is the friendly hostile takeover because it'll just deploy a bot or a crypto miner and might even patch your system. Just don't put . on your PATH. And if you do, append it - <PATH=$PATH:.>. This way, /usr/bin/foo will win against ./foo.
- dahart 7y agoHaving a dot at the end of the path also trivially mitigates that particular scenario while still providing the convenience of being able to run an executable without having to always type dot-slash. I guess the reasons not to put the dot at the end are mainly about common typo attacks, but I’m partial to dot at the end.