Skip to content

api-server: an unknown logs mode leaves logs-start with no response #8134

Description

@DavidePrincipi

Steps to reproduce

  • Send a logs-start action over the api-server WebSocket with a mode that is neither tail nor dump, for example: {"action":"logs-start","payload":{"id":"1","mode":"foo","entity":"cluster"}}
  • Alternatively, run api-server-logs logs --mode=foo

Expected behavior

The caller always gets an answer: an error message naming the unsupported mode. The CLI exits non-zero.

Actual behavior

Nothing is written back at all, and no logcli process is ever started.

logsAction.Mode is taken verbatim from the client payload. The switch at core/api-server/socket/action.go:136 handles tail and dump; any other value falls through leaving mode = "", which is appended to args as an empty argument. Neither if logsAction.Mode == "tail" nor == "dump" then matches, so no goroutine is started and no response is produced:

  • Over the WebSocket, the client waits indefinitely for a logs-start event that never arrives.
  • In the CLI, Logs() calls wg.Add(1) and then wg.Wait() (core/api-server/api-server-logs.go:96,122), and nothing will ever call wg.Done(), so api-server-logs --mode=foo hangs forever.

Reachable by any authenticated WebSocket client. It neither crashes nor leaks anything — the handler simply goes silent — so this is a robustness gap, not a security issue.

Suggested fix

Add a default: arm to the mode switch so the caller is always answered:

default:
	writeLogsError(s, logsAction.Id, "unknown logs mode: "+logsAction.Mode, wg)
	return

This also drops the stray empty-string argument, which would have produced a malformed logcli invocation had either branch run.

Components

ns8-core 3.21.0 (also present on main, 3.21.1-dev.1) — core/api-server, WebSocket logs-start action and the api-server-logs CLI.

See also

Pre-existing behaviour. Found while reviewing NethServer/ns8-core#1272, whose goal was to report logcli errors instead of dropping them; this is the last silent-hang path left in the handler. Deliberately kept out of that PR's scope.

Metadata

Metadata

Labels

No labels
No labels

Type

Projects

Status
Backlog

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions