On Fri, Jul 02, 2021 at 05:45:23PM +0200, Phi Debian wrote: > Regarding the code injection I am not sure I got it. > > If you are sitting at a prompt, why would you trick > > unicorn:~$ njobs_ref 'x[0$(date>&2)]' > > when you could simply type > unicorn:~$ date > > I assume protected script/source (the ones you can't write into), are wise > enough not to run command based on user input, in short I guess no > protected script are doing thing like read in; eval $in :) that is the > simplest code injection :) and then would never let you have a chance to > enter 'x[0$(date>&2)]' at any time.
For functions that you've written exclusively for personal use, it's not an immediate concern. It's more of a thing that you want to be aware of for the future. Where it becomes important is when you're writing scripts for other people to use, or which run as different user accounts, or with different privileges. The classic example of this is a script that's run by a web server in a CGI environment, which accepts query parameters from the end user. If one of those query parameters is used in an unsafe way, it can execute undesired commands on the web server. Of course, there are *many* other places that shell scripts are used, such as booting an operating system, starting various services, and so on. In some of these cases, there is no external input being read, or the external inputs are "trusted" files owned and edited only by the system admin (root). But in other cases, untrusted input may be read. So, there's merit in adopting a proactive strategy to shell script security. Maintaining a slightly paranoid mindset can help you spot potential security holes and possibly avoid disasters.
