1

For user scripts, the usual advice is to append their directory to $PATH in one's .profile:

PATH="$PATH:$HOME/.myscripts" # or .bin or whatever

Apparently that is safer than prepending it: PATH="$HOME/.myscripts:$PATH"

But doing it the safe way means your script is going to be trumped by a system package with the same name. If you name your script mount or import, for example, unexpected things will happen when you try to use it.

I understand that many will see this as a feature, not a bug. But personally I want to be able to name my scripts whatever I like, including import, and have them run without surprises.

As I understand it, the risks of prepending are:

  • a malicious script could rewrite ls etc without having root access (but is this really a concern when installing software from standard distro repos only?)
  • a system package might call your user script instead of the other system package (but do user packages ever call mount or whatever without the full path, in practice? Seems like a bad idea)

How serious, exactly, are the security implications of prepending via .profile on a single-user system?

Improve this question
4
  • 2
    if a malicious script can rewrite ls somewhere where the user has write access, it can probably just set an alias for ls or modify PATH too.
    – ilkkachu
    Commented Dec 9, 2021 at 21:01
  • 3
    The answer to your second question is certainly "yes", rendering the rest of it moot.
    – Michael Homer
    Commented Dec 9, 2021 at 21:02
  • 1
    This is one way that bash functions are preferable to small scripts. A mount function will exist in your interactive shell session, and be used before any mount command in the PATH, but the function will not interfere with a 3rd party script that invokes mount
    – glenn jackman
    Commented Dec 9, 2021 at 22:21
  • 2
    I think the risk is limited and subjective. Scripts usually invoke commands by name only so changing basic commands like mount can be dangerous. But there are examples where you might want to change the behaviour (swapping out Java or python runtimes). There you can prepend the path and don't beat yourself up about the security. After all malicious code can rewrite your profile and change your PATH.
    – Philip Couling
    Commented Dec 9, 2021 at 22:27

1 Answer 1

Reset to default
2

I think you hit the nail on the head right here:

unexpected things will happen when you try to use it

If you create an executable that name squats with a standard command, you're asking for trouble. But it's your computer (I assume) so ultimately you can do what you like with it, best practice or otherwise.

A safer way to achieve what you're looking for would be to set the PATH in the append fashion, give your script a "safe" name (such as jortstek_mount) and then add an alias or trivial function to your shell profile along these lines

mount() {
  command jortstek_mount "$@"
}
Improve this answer
6
  • OK I get that. The paradigmatic example being mount, like in the question. But if I have literally written my own script called mount then surely I will not be surprised about needing to do /bin/mount if I want the real thing. Hence can't see why it's asking for trouble. Thanks, upvoted anyway.
    – Jortstek
    Commented Dec 9, 2021 at 21:11
  • 2
    @jortstek you may be surprised by what is actually a bash script in /usr/bin. "mount" is a superuser program so may be protected by sudo rewriting your path. But let's say you replace "rm" with something that moves to trash... your trash can could fill up mighty fast as many scripts expect to be able to creat temp files and "rm" them after.
    – Philip Couling
    Commented Dec 9, 2021 at 22:33
  • 1
    You might be expecting mount (or whatever else is name squatting) to behave in a particular way, but some other tool you might use is going to have a different expectation of mount (etc) behaviour. It's not a certainty that you will encounter an issue, but there's an element of risk. With luck, such an issue will just be an weird failure that does no harm, but is it worth taking the chance?
    – bxm
    Commented Dec 9, 2021 at 22:34
  • Thanks for the ideas. What I want is a completely free namespace without risk of clashes, and it seems the risk is small but genuine. Functions are indeed the way to go.
    – Jortstek
    Commented Dec 9, 2021 at 23:59
  • 1
    _mount is not a safe name if you're using zsh as your shell as there, completion functions are typically named in that fashion. _mount there is the completion helper function for the mount utility. Your mount function would end up invoking the completion function for mount instead of the _mount script.
    – Stéphane Chazelas
    Commented Dec 10, 2021 at 8:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .