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.
Steps to reproduce
logs-startaction over the api-server WebSocket with amodethat is neithertailnordump, for example:{"action":"logs-start","payload":{"id":"1","mode":"foo","entity":"cluster"}}api-server-logs logs --mode=fooExpected 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
logcliprocess is ever started.logsAction.Modeis taken verbatim from the client payload. The switch atcore/api-server/socket/action.go:136handlestailanddump; any other value falls through leavingmode = "", which is appended toargsas an empty argument. Neitherif logsAction.Mode == "tail"nor== "dump"then matches, so no goroutine is started and no response is produced:logs-startevent that never arrives.Logs()callswg.Add(1)and thenwg.Wait()(core/api-server/api-server-logs.go:96,122), and nothing will ever callwg.Done(), soapi-server-logs --mode=foohangs 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:This also drops the stray empty-string argument, which would have produced a malformed
logcliinvocation had either branch run.Components
ns8-core 3.21.0 (also present on
main, 3.21.1-dev.1) —core/api-server, WebSocketlogs-startaction and theapi-server-logsCLI.See also
Pre-existing behaviour. Found while reviewing NethServer/ns8-core#1272, whose goal was to report
logclierrors instead of dropping them; this is the last silent-hang path left in the handler. Deliberately kept out of that PR's scope.