Dear Team,
We are currently performing a security hardening exercise on our RHEL 8.10 base
environment, where we have enabled command digest validation in the sudoers
configuration as per security and compliance requirements.
After enabling the digest option, we observed an unexpected behavior across
multiple third-party ksh/bash scripts that rely on $0 for determining the
script name or script path.
Problem Description
* Several scripts reference $0 to derive:
* Script name
* Script directory
* Relative paths for configuration/log files
* Once sudo digest is enabled, these scripts start misbehaving on lines
that use $0.
Observed Behavior
Instead of resolving to the actual script path or script name, $0 resolves to a
file descriptor value, for example:
/dev/fd/6
This leads to incorrect path resolution and causes failures in:
* Relative file lookups
* Logging
* Script chaining or sourcing logic
Expected Behavior
Before enabling sudo digest (or when digest is disabled), $0 correctly resolves
to:
/full/path/to/script.sh
or an equivalent script identifier.
Environment Details
* OS: RHEL 8.10
* Shells affected: bash, ksh
* sudo: Digest enabled in sudoers
* Execution context: Scripts executed via sudo
Found Files in spark package-
* files/install/bin/install.sh: SOURCE_DIR="$(get_full_path
$(dirname "$0"))"
* files/misc/SparkMaster: echo "Usage: 'basename $0'
start|stop|status|start-all|stop-all"
* files/misc/SparkSlave: echo "Usage: 'basename $0'
start|stop|stop-all|status"
Request
We understand that this behavior is related to how sudo executes scripts when
digest validation is enabled (execution via file descriptors).
However, since multiple third-party scripts depend on $0, modifying all scripts
is not feasible on our side.
We would appreciate your guidance on:
* Whether your scripts officially support execution with sudo digest enabled
* Any recommended configuration, wrapper, or compatibility approach
* Planned fixes or best practices to avoid dependency on $0 in such
scenarios
This information will help us align our security posture while maintaining
compatibility with your tooling.
Thank you for your support.
We look forward to your guidance.
Best regards,
Satyendra Paterya
