feat(gateway): match systemd service name to gateway name

[bernie-g]

Summary

The systemd service name now matches the gateway name directly (e.g. my-gateway.service instead of the hardcoded infisical-gateway.service), with config at /etc/infisical/gateways/<name>.conf. Legacy installs are detected and updated in place with a warning to migrate. The systemd uninstall command now requires a gateway name argument.

Companion docs PR: Infisical/infisical#6624

Test plan

• All install/uninstall edge cases tested in Docker with systemd

[infisical-review-police]

💬 Discussion in Slack: #pr-review-cli-244-feat-gateway-match-systemd-service-name-to-gateway-name

Posted by Review Police — reviews, comments, new commits, and CI failures will stream into this channel.

[greptile-apps]

Greptile Summary

This PR changes systemd service names to match gateway names (e.g., my-gateway.service instead of infisical-gateway.service), with config at /etc/infisical/gateways/<name>.conf. Legacy installs are detected by reading the old service/config files and handled transparently, and the uninstall subcommand now requires the gateway name as an argument.

• systemd.go: Adds resolveInstallPaths + detectLegacyService to pick either the legacy service or a new per-name service; all three install functions now return the service name so the caller can systemctl enable it.
• enroll.go: Extracts readKeyFromConfFile(path, key) from loadConfKey so it can be reused by the new legacy-detection code in systemd.go.
• gateway.go: Threads the returned service name through all three install branches and passes it to systemctl enable; uninstall now requires exactly one positional argument.

Confidence Score: 3/5

The core rename logic and legacy migration path are sound, but the install functions write token-bearing config files to paths derived directly from unsanitized user input while running as root.

The gateway name is taken from the CLI and embedded directly into /etc/systemd/system/.service and /etc/infisical/gateways/.conf. Because the install path requires root, a name containing ../ components could write or overwrite arbitrary system files and embed authentication tokens in unexpected locations.

packages/gateway-v2/systemd.go warrants a close look — specifically the serviceFilePath, gatewayConfigPath, and all three public Install* functions that accept and propagate the unsanitized name parameter.

Security Review

• Path traversal via unsanitized gateway name (packages/gateway-v2/systemd.go): The name argument from the CLI is used verbatim in serviceFilePath and gatewayConfigPath to construct paths under /etc/systemd/system/ and /etc/infisical/gateways/. Because all three install functions execute as root, a crafted name (e.g., ../../etc/cron.d/evil) would write config content — which includes authentication tokens — to an arbitrary path on the host. No allowlist validation is applied before the paths are constructed or written.

Important Files Changed

Filename	Overview
packages/gateway-v2/systemd.go	Core systemd management rewrite: adds legacy detection/migration and per-gateway service naming. Gateway name is interpolated into root-owned file paths without validation, enabling path traversal. Two additional minor error-handling gaps exist.
packages/gateway-v2/enroll.go	Refactors loadConfKey to delegate to a new readKeyFromConfFile helper that accepts a path directly; no functional logic changes.
packages/cmd/gateway.go	Updates install commands to capture and use the returned service name, and adds a required gateway-name argument to the uninstall command. Logic is straightforward and consistent.

_{Reviews (1): Last reviewed commit: "refactor(gateway): remove no-op serviceN..." | Re-trigger Greptile}