Description
Description
Even after the proxy refactor, NemoClaw still injects proxy-related lines into the sandbox user’s shell RC files (/.bashrc and /.profile), while the test and security expectations require that RC files contain no proxy entries and that all proxy configuration live in a root‑owned script (e.g. /etc/profile.d/nemoclaw-proxy.sh). With current builds, grep -i proxy ~/.bashrc ~/.profile returns NemoClaw‑inserted “Source runtime proxy config” lines that source /tmp/nemoclaw-proxy-env.sh, causing the “no proxy entries in RC files” test to fail. This leaves NemoClaw still modifying per-user RC files, contrary to the test’s stated goal of moving all proxy wiring out of user RC files.
Environment
-
Platform: Linux (e.g. Ubuntu 22.04 / 24.04 / 26.04), inside a NemoClaw sandbox.
-
NemoClaw: Installed and working (e.g. via
curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash). -
OpenShell gateway: Running via Docker as per Quickstart.
-
Preconditions for this test:
-
NemoClaw installed.
-
Sandbox onboarded and running; entrypoint completed (initialization done).
-
No host-level
HTTP_PROXY / HTTPS_PROXY overrides beyond NemoClaw’s proxy configuration.
Steps to Reproduce
Preconditions
-
Install NemoClaw and onboard a sandbox (e.g.
prachi-new-sb) until it reaches a running/ready state. -
Ensure no extra host‑level
HTTP_PROXY / HTTPS_PROXY env overrides are set (beyond any NemoClaw-managed proxy), per the test precondition.
Repro steps
-
From the host, connect to the sandbox:
bash
nemoclaw connect -
Inside the sandbox, locate the proxy script directory:
bash
ls -la /etc/profile.d/ 2>/dev/null || ls -la /sandbox/.profile.d/ 2>/dev/null -
Check ownership and permissions of the NemoClaw proxy script:
bash
stat -c '%U:%G %a' $(ls /etc/profile.d/nemoclaw-proxy.sh 2>/dev/null || ls /sandbox/.profile.d/nemoclaw-proxy.sh 2>/dev/null) -
Inspect user RC files for any proxy entries:
bash
grep -i proxy ~/.bashrc ~/.profile 2>&1 -
Verify proxy env vars for completeness:
bash
echo "$HTTP_PROXY" echo "$HTTPS_PROXY" -
Exit the sandbox:bash
exit
Expected Result
Per the test case:
Actual Result
Inside the sandbox:
-
Proxy script exists and is root‑owned, read‑only:
bash
echo "$HTTP_PROXY" # http://10.200.0.1:3128 echo "$HTTPS_PROXY" # http://10.200.0.1:3128 ls -la /etc/profile.d/ total 12 drwxr-xr-x 1 root root 4096 May 16 20:13 . drwxr-xr-x 1 root root 4096 May 19 16:59 .. -r--r--r-- 1 root root 141 May 16 20:13 nemoclaw-proxy.sh stat -c '%U:%G %a' /etc/profile.d/nemoclaw-proxy.sh # root:root 444 -
User RC files do contain NemoClaw proxy-related lines:
bash
grep -i proxy ~/.bashrc ~/.profile 2>&1 /sandbox/.bashrc:# Source runtime proxy config /sandbox/.bashrc:[ -f /tmp/nemoclaw-proxy-env.sh ] && . /tmp/nemoclaw-proxy-env.sh /sandbox/.profile:# Source runtime proxy config /sandbox/.profile:[ -f /tmp/nemoclaw-proxy-env.sh ] && . /tmp/nemoclaw-proxy-env.sh
Observations:
-
The root‑owned
/etc/profile.d/nemoclaw-proxy.sh script exists and is correctly protected (root:root 444), which aligns with the hardened proxy design. -
However, RC files still contain NemoClaw‑inserted proxy source stanzas (
# Source runtime proxy config lines and sourcing of /tmp/nemoclaw-proxy-env.sh). -
This contradicts the test’s requirement that RC files contain no proxy entries added by NemoClaw and that the standalone script be the exclusive proxy source.
-
Even though this is an improvement over the earlier behavior (where RC files had
# BEGIN NEMOCLAW PROXY blocks and inline proxy exports), it still fails the stricter “no proxy entries in RC files at all” expectation.
In other words:
-
The proxy hardening is only partially complete: NemoClaw has moved the core proxy logic into a root‑owned script but still edits
~/.bashrc and ~/.profile to inject a proxy source stanza. -
For environments and tests that require NemoClaw to leave user RC files entirely untouched (no proxy‑related lines), this is a regression relative to the updated spec, and
grep -i proxy ~/.bashrc ~/.profile correctly flags it as a failure.
Bug Details
| Field |
Value |
| Priority |
Unprioritized |
| Action |
Dev - Open - To fix |
| Disposition |
Open issue |
| Module |
Machine Learning - NemoClaw |
| Keyword |
NemoClaw, NEMOCLAW_GH_SYNC_APPROVAL |
[NVB#6192910]
Description
Description
Even after the proxy refactor, NemoClaw still injects proxy-related lines into the sandbox user’s shell RC files (
and/.bashrc/.profile), while the test and security expectations require that RC files contain no proxy entries and that all proxy configuration live in a root‑owned script (e.g./etc/profile.d/nemoclaw-proxy.sh). With current builds,grep -i proxy ~/.bashrc ~/.profilereturns NemoClaw‑inserted “Source runtime proxy config” lines that source/tmp/nemoclaw-proxy-env.sh, causing the “no proxy entries in RC files” test to fail. This leaves NemoClaw still modifying per-user RC files, contrary to the test’s stated goal of moving all proxy wiring out of user RC files.Environment
curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash).HTTP_PROXY/HTTPS_PROXYoverrides beyond NemoClaw’s proxy configuration.Steps to Reproduce
Preconditions
prachi-new-sb) until it reaches a running/ready state.HTTP_PROXY/HTTPS_PROXYenv overrides are set (beyond any NemoClaw-managed proxy), per the test precondition.Repro steps
nemoclaw connectls -la /etc/profile.d/ 2>/dev/null || ls -la /sandbox/.profile.d/ 2>/dev/nullstat -c '%U:%G %a' $(ls /etc/profile.d/nemoclaw-proxy.sh 2>/dev/null || ls /sandbox/.profile.d/nemoclaw-proxy.sh 2>/dev/null)grep -i proxy ~/.bashrc ~/.profile 2>&1bashecho "$HTTP_PROXY" echo "$HTTPS_PROXY"exitExpected Result
Per the test case:
proxy-env.shin the spec, with root:root ownership and read‑only permissions, acting as the sole source of proxy env vars.staton that script returns: bashroot:root 444so the sandbox user cannot modify it.
Step 4:
grep -i proxy ~/.bashrc ~/.profilereturns no matches.~/.bashrcnor~/.profilecontains proxy lines or NemoClaw markers.# BEGIN NEMOCLAW PROXY/# END NEMOCLAW PROXYblocks and noHTTP_PROXY/HTTPS_PROXYexports appended by NemoClaw.HTTP_PROXYandHTTPS_PROXYare correctly set to the gateway proxy URL (for examplehttp://10.200.0.1:3128)..bashrc) is the sole source of proxy env vars.Actual Result
Inside the sandbox:
echo "$HTTP_PROXY" # http://10.200.0.1:3128 echo "$HTTPS_PROXY" # http://10.200.0.1:3128 ls -la /etc/profile.d/ total 12 drwxr-xr-x 1 root root 4096 May 16 20:13 . drwxr-xr-x 1 root root 4096 May 19 16:59 .. -r--r--r-- 1 root root 141 May 16 20:13 nemoclaw-proxy.sh stat -c '%U:%G %a' /etc/profile.d/nemoclaw-proxy.sh # root:root 444grep -i proxy ~/.bashrc ~/.profile 2>&1 /sandbox/.bashrc:# Source runtime proxy config /sandbox/.bashrc:[ -f /tmp/nemoclaw-proxy-env.sh ] && . /tmp/nemoclaw-proxy-env.sh /sandbox/.profile:# Source runtime proxy config /sandbox/.profile:[ -f /tmp/nemoclaw-proxy-env.sh ] && . /tmp/nemoclaw-proxy-env.shObservations:
/etc/profile.d/nemoclaw-proxy.shscript exists and is correctly protected (root:root 444), which aligns with the hardened proxy design.# Source runtime proxy configlines and sourcing of/tmp/nemoclaw-proxy-env.sh).# BEGIN NEMOCLAW PROXYblocks and inline proxy exports), it still fails the stricter “no proxy entries in RC files at all” expectation.In other words:
~/.bashrcand~/.profileto inject a proxy source stanza.grep -i proxy ~/.bashrc ~/.profilecorrectly flags it as a failure.Bug Details
[NVB#6192910]