For a toy CLI application I'm writing, I'd like to store a string with an user defined command that will be executed periodically (like shell -c <command_string>).

I have seen other applications do this, for example in fzf you can set an environment variable with a command to be executed every time the application runs.

I'm worried about an attacker being able to modify this string with something malicious, but I don't know if my concern is justified: if the attacker is able to modify this string, maybe it already has access to the user's system.

The string with the command will be stored in a SQLite database along with other application data. (I'm aware that I have to take measures when I store the data to avoid SQL injection)

  • It is impossible to tell from the current information if the attacker is able to modify the string. It is basically like asking if a blue car has enough fuel, i.e. expecting a useful answer while providing no actually usable information for this. Feb 22, 2021 at 20:53
  • thanks for the answer @SteffenUllrich, I think I'm confused to the point in which I don't know what information could be useful. I will edit the question and do my best to clarify
    – roperzh
    Feb 22, 2021 at 20:57
  • To answer if a string can be changed on need to know all the ways this could be possible in your specific scenario. For this one would need to know the full architecture of your system, all its bugs, all users who have access etc. All what can be said with the current information is that there is no way to change the string based on the information provided, which does not mean that there is no way to change the string. Feb 22, 2021 at 20:59

1 Answer 1


This boils down to a core question:

  • Is sh a valid command?

If so, then the user already has access; there is nothing further to contemplate in the question as-stated; a "malicious" user will have just as much access as a "non-malicious" and you should go to a regular threat model for potentially-malicious logged-in users, such as sandboxing.

If not, then you really ought to:

  1. Set up a whitelist of permitted commands
  2. Ensure you are sanitizing (or, better-yet, parameterizing) user input appropriately
    • example: if your toy CLI application is a Python program—
      def handle_user_input(untrusted_string: str):
          user_command = shlex.split(untrusted_string) #: list
          if not user_command[0] in whitelist:
             raise ValueError("Non-whitelisted command.")
      def event_callback(user_command: list):
          """Is called on the parameterized, whitelist-checked user_command list every interval"""
          assert isinstance(user_command, list)
          assert user_command[0] in whitelist
  3. Consider contingencies for when one of the whitelisted programs has a shell-execution vulnerability anyway, and this use-case reduces to what where sh is allowed (i.e.: sanbox the user.)

Your threat-model is poorly-defined in the question as-stated, but I hope this helps.

Also, check out this answer on another question — he expresses much better what I've tried to communicate here.

Allowing them to "run a command" is tantamount to letting them log in (after all, that's what "logging in" gates in the first place.)

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