View Issue Details

IDProjectCategoryView StatusLast Update
0037359mantisbtbugtrackerpublic2026-08-26 14:58
Reporterrnijhof Assigned Todregad  
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionopen 
Product Version2.27.0 
Target Version2.29.0 
Summary0037359: Admin check reports false FAIL when Graphviz path is outside open_basedir
Description

Summary

On a clean MantisBT 2.28.4 installation, the admin installation check reports multiple FAIL results when PHP open_basedir restricts access to the default Graphviz path /usr/bin/.

One of the reported failures appears to be misleading:

absolute_path configuration option has a trailing directory separator

The absolute_path value is correct and the corresponding condition evaluates to true.

Environment

  • MantisBT: 2.28.4
  • PHP: with open_basedir enabled
  • Example open_basedir:

    /var/www/example.com
  • Default Graphviz path:

    $g_graphviz_path = '/usr/bin/';
  • Relationship graphs:

    $g_relationship_graph_enable = OFF;

Steps to reproduce

  1. Install a clean MantisBT 2.28.4 release.
  2. Configure PHP with an open_basedir restriction, for example:

    open_basedir = /var/www/example.com
  3. Leave the default Graphviz configuration unchanged:

    $g_graphviz_path = '/usr/bin/';
  4. Open the MantisBT Admin → Check Installation page.

Actual result

The following checks are reported as FAIL:

absolute_path configuration option has a trailing directory separator

graphviz_path configuration option points to a valid directory
The path '/usr/bin/' is not a valid directory.

graphviz_path configuration option points to an accessible directory
The path '/usr/bin/' is not accessible.

The Graphviz failures are understandable because /usr/bin/ is outside the configured open_basedir.

However, the absolute_path check is also marked as FAIL, even though its value is correct.

Example runtime value:

/var/www/example.com/public_html/mantisbt-2.28.4/

The exact condition used by the admin check:

substr( $t_path['config_value'], -1, 1 ) == DIRECTORY_SEPARATOR

evaluates to:

bool(true)

Additional investigation

Calling:

realpath('/usr/bin/');

results in an open_basedir restriction warning and returns:

bool(false)

The admin check function contains:

$t_unhandled = check_unhandled_errors_exist();

if( $p_pass && !$t_unhandled ) {
    $t_result = GOOD;
} elseif( $p_warning && !$t_unhandled || $t_unhandled == E_DEPRECATED ) {
    $t_result = WARN;
} else {
    $t_result = BAD;
}

This appears to allow a successful check ($p_pass === true) to be displayed as FAIL when an unrelated unhandled warning is present.

Expected result

  • The absolute_path check should report PASS.
  • A Graphviz-related warning or failure should not change the result of unrelated configuration checks.
  • Ideally, the Graphviz path should not be validated as a required path when Graphviz functionality is disabled:

    $g_relationship_graph_enable = OFF;

Notes

The issue is reproducible with a clean MantisBT 2.28.4 installation, so it does not appear to be caused by modified or leftover files from an upgrade.

All paths in this report are anonymized examples.

TagsNo tags attached.

Activities

dregad

dregad

2026-08-26 05:49

developer   ~0071375

Thanks for the detailed report.

So there are actually 2 distinct bugs here:

  1. we should not be checking graphviz_path when relationship_graph_enable is OFF
  2. the PHP warning triggered by calling realpath() on graphviz_path when building the list of configs to check is incorrectly reported as failure for absolute_path (which happens to be the first path in the list)

I believe this was introduced when the graphviz_path config was added in 0034609 (2.27.0), more specifically by commit MantisBT master 25bf40e9 which updated the admin check.

dregad

dregad

2026-08-26 06:05

developer   ~0071376

Proposed fix: PR https://github.com/mantisbt/mantisbt/pull/2267
@rnijhof Testing and feedback welcome

rnijhof

rnijhof

2026-08-26 08:23

reporter   ~0071377

@dregad, thks for your quick response! Unfortunately, I’m no longer able to test the solution. In the meantime, I’ve migrated our environment to the new version, as I assumed the warnings did not apply to our installation.

dregad

dregad

2026-08-26 10:01

developer   ~0071378

no longer able to test the solution

OK, sp we'll just have to trust that my unit tests were good enough then ;-)

I assumed the warnings did not apply to our installation

Rightly so.

rnijhof

rnijhof

2026-08-26 14:57

reporter   ~0071379

Last edited: 2026-08-26 14:58

OK, sp we'll just have to trust that my unit tests were good enough then ;-)

Hahaha, i agree :)