Remote installer hides group-writable binary directory rejection #627

Problem

An existing, executable orx can be silently treated as absent when its binary
or containing directory has group/other write permission. After using the
remote installer, the UI then reports:

The installer finished, but no working orx binary was found on 'example'.

This is a misleading installation diagnostic, not a request to relax the
remote executable trust policy. It is present in v0.2.18 and main at
603558c.

Minimal reproduction

Use a disposable Linux account or temporary test fixture, not a shared tool
directory. Give an executable that prints orx 1.2.3 mode 755, and give its
containing directory mode 775. The existing probe in
src/commands/up_remote.rs rejects the directory via -perm -020, returns no
binary markers, and loses the reason for rejection. Changing only the directory
to 755 allows the same executable to pass. No real host details or credentials
are needed to reproduce this behavior.

Expected behavior

Keep rejecting group/world-writable installations without executing them, but
explain the permission failure and how to inspect it. Any permission repair
should be explicit and manual; an intentionally shared directory should not be
modified automatically.

Related work

PR #357 also mentions group-writable installation directories, but proposes a
primary-group exception and unrelated POSIX path changes. This report is scoped
to an actionable diagnostic while preserving the existing ownership and
permission checks, including for the user's primary group.

Slack feedback reports: 3

Slack feedback report

Report ID: 01a13e2e-da7f-7157-8744-3f3a9a48148d
Permalink: https://alphaxiv.slack.com/archives/C0C46L5EFRT/p1792044621609309

Original feedback:

New OpenResearch agent feedback (bug)

Summary: Remote host dialog reports no working orx binary after SSH preflight is ready

Details:
A configured SSH host shows The installer finished, but no working orx binary was found. Remote host is Linux x86_64. Noninteractive SSH command -v orx resolves through a symlink in home .local bin to home .cargo bin. Both paths execute and report orx 0.2.18, matching the local CLI. orx compute show ssh reports reachable true and toolsFound true. orx compute test ssh for the same saved host exits zero with ready true, reachable true, toolsFound true, and missingTools empty. It also warns that SSH connection sharing is unavailable with Operation not permitted. Expected the UI to accept the host or refresh the prior error; actual UI continues showing the no working binary dialog. Host address and username redacted.

CLI version: 0.2.18 (production), backend 0.2.18

Report ID: 01a13e2e-da7f-7157-8744-3f3a9a48148d

https://www.autoarxiv.org/admin/feedback

Status note: not reopened (issue is In Review, not Merged/Done).

Slack feedback report

Report ID: 01a1449d-f2ce-7a73-9f73-49c01119ed7c
Permalink: https://alphaxiv.slack.com/archives/C0C46L5EFRT/p1792152565632779

Original feedback:

New OpenResearch agent feedback (bug)

Summary: Remote install reports missing binary when install directory inherits group-write ACL

Details:
OpenResearch 0.2.19 macOS app connecting to an Ubuntu SSH host. Installer completes and installed binary runs successfully with version 0.2.19, but GUI reports The installer finished, but no working orx binary was found. Install bin directory inherited mode 2775 and default ACL from shared storage. probe_remote_orx_path silently rejects it because parent directory is group writable. Removing only group write from the bin directory makes the exact application probe return the expected path and version. Expected an explicit unsafe-directory error and guidance rather than missing binary. Private host details and installation paths omitted.

CLI version: 0.2.19 (production), backend 0.2.19

Report ID: 01a1449d-f2ce-7a73-9f73-49c01119ed7c

https://www.autoarxiv.org/admin/feedback

Status note: not reopened (issue is In Review, not Merged/Done).

Slack feedback report

Report ID: 01a15466-03f6-7212-a2f9-f6193a1764d9
Permalink: https://alphaxiv.slack.com/archives/C0C46L5EFRT/p1792417335293399

Original feedback:

New OpenResearch agent feedback (bug)

Summary: SSH installer succeeds but rejects the installed CLI when its bin directory is group writable

Details:
OpenResearch macOS app and Linux x86_64 CLI version 0.2.19. Remote installation completes, then the app reports: The installer finished, but no working [backtick]orx[backtick] binary was found on [remote host]. The installed binary runs successfully by absolute path. Its parent cargo bin directory has mode 0775 and the binary has mode 0755. Reproducing the app binary discovery permission check confirms it rejects the group-writable parent directory. Removing only the parent directory group-write permission makes the same discovery check pass. The CLI then reports dashboard protocol 2. Expected: installation should validate and normalize the install directory permissions or explain the precise permission failure. Actual: generic binary-not-found error after successful installation. Workaround: change the user-owned cargo bin directory from mode 0775 to 0755. Host alias and user-specific paths withheld for privacy. The bracketed name [backtick] represents a literal backtick character.

CLI version: 0.2.19 (production), backend 0.2.19

Report ID: 01a15466-03f6-7212-a2f9-f6193a1764d9

https://www.autoarxiv.org/admin/feedback

Status note: not reopened (issue is In Review, not Merged/Done).