This documentation supports the 11.3 version of BMC Discovery.

To view an earlier version of the product, select the version from the Product version menu.

Restricting paths on which you can execute discovery commands

Discovery commands run on discovery targets with sufficient permission to determine information that is returned to BMC Discovery. Many discovery requests use paths that are dynamically determined, based on information obtained from the target environment. For example, a pattern might query the location of installed software, such as the installation path of a web server, and then use discovery.runCommand to execute commands using that path to get additional detailed information. 

Some organizations have policies stating which paths might be used to run commands. You can specify paths that, if determined as part of a query, must not be used by  BMC Discovery to run additional commands. Paths can be specified for each Windows, UNIX, Linux, and related discovery platforms. 

The commands to run must be specified in patterns using the Future.runCommand function and the path and command are checked against any path restriction you specify for individual platforms. The Future.runCommand function is similar to discovery.runCommand but has an additional parameter specifying the path to the command. The new parameter is intended to be merged with discovery.runCommand in a future release, and the Future.runCommand function deprecated.

The path restrictions tab enables you to add restrictions for individual discovery platforms. You can add a number of individual allow or deny rules, and these are evaluated in order, and the default determines what happens if nothing higher matches

A default restriction is provided that blocks unwanted characters in a path. It uses the following regular expression: 

  • UNIX, Linux, and related platforms: .*[[`$&;|!?*~<>]
  • Windows platforms: .*[%;&|*?<>]

To restrict paths on which Future.runCommand can execute commands

In this example, your company policy does not permit installation of software in the /usr/local/bin/ directory. This shows a simple restriction, showing how to prevent Future.runCommand running any command in the /usr/local/bin/  directory:

  1. From the main menu, click the Administration icon. 
    The Administration page displays. 

  2. In the Discovery section, click Platforms.
    The Discovery Platforms page lists the categories for which discovery commands are provided. Each category displays headers that link to pages containing details of discovery methods used. 

  3. Click the platform link for the OS you want to restrict the path on which commands can be run.
  4. Click the Path Restrictions tab. 

  5. Select Deny from the Add a restriction drop down list.
  6. Enter the regular expression into the Add a restriction field that matches the path you want to restrict. See regular expression note.
    In this example, enter /usr/local/bin/ 

  7. Click Add
  8. Test the restriction by entering an command that might be run in that path.
    1. Enter /usr/local/bin/testcommand in the Test a path field. 
    2. Click Test.
    If the tested command matches any of the rules, the first matching rule is highlighted.

More complex examples

This section shows the rules you would enter into the UI to make more complex restrictions.

To specify a restricted path with an exception

You might choose to install and use one command in the /usr/local/bin/ directory, but only permit the use of that command (goodcommand) in that directory. Use the following rules, in this order:

  1. Allow – /usr/local/bin/goodcommand$
  2. Deny – /usr/local/bin/
  3. Allow – the final default rule for all unmatched paths. 

Similarly on Windows.

  1. Allow – .*\\program\ files\\directory\\goodcommand$
  2. Deny – .*\\program\ files\\directory\\
  3. Allow – the final default rule for all unmatched paths.


On Windows platforms, the regular expression matching is not case-sensitive.

To specify a permitted path with an exception

You might choose to permit only commands except for one  (badcommand) in the /usr/local/bin/ directory to be used, no other commands could be used. Use the following rules, in this order:

  1. Deny – /usr/local/bin/badcommand$
  2. Allow – /usr/local/bin/
  3. Deny – the final default rule for all unmatched paths. The final rule can be switched to Deny from the default Allow, by clicking Switch to Deny.

To determine where commands are blocked

Where a command is blocked, the corresponding Discovered Command Result node has a status of blocked. You can see a report showing all blocked discovery accesses from the Discovery Run page. On the DiscoveredResultCommand node, the failure_reason atrribute is set to RequestBlocked.

  1. From the Discovery Status page (Manage > Discovery), click Recent Runs.
    The list of recent Discovery Runs is displayed.

  2. Click the Discovery Run you want to examine.

  3. From the Reports menu of the Discovery Run page, select Blocked Requests
    The Blocked Requests report displays. 


  4. Click a row in the Block Request list. The corresponding Discovered Command Result page is displayed. The attributes related to the blocking are:
    • Failure Reason—for a blocked command this is RequestBlocked
    • Failure Cause—the restriction that triggered the block, for example, Execution blocked by Linux path restriction '/usr/local/bin'
    • Command—the command that was blocked, for example, "/usr/local/bin/vmtoolsd" -v

Regular expression note 

The regular expressions that you enter into the path restriction field are only anchored at the start, not at the end. This means that the regular expression /usr would match the following:

  • /usr
  • /usr/bin

  • /usrotherdirectory

  • /usrotherdirectory/bin

Regular expressions on Windows

On Windows platforms, the regular expression matching is not case sensitive.

Where short 8.3 format paths are encountered on Windows, they are expanded to the full path. Consequently you do not need to consider 8.3 paths when creating the regular expression. 

Was this page helpful? Yes No Submitting... Thank you