Description

Hi 👋, and thanks for the TTY fields and the very clear docs/features/exec-tty-field.md!

event.hasTty is false for a shell on /dev/pts/0, which is where the first kubectl exec -it into a container lands. node-agent pins ghcr.io/inspektor-gadget/gadget/trace_exec:v0.48.1 (pkg/containerwatcher/v2/tracers/exec.go), which only emits the tty index, so has(event.ttyMajor) is never true and hasTty falls back to an index where 0 means both "no terminal" and /dev/pts/0.

Good news: inspektor-gadget/inspektor-gadget#5714 landed in v0.55.0 and emits the terminal device number. Since node-agent already reads tty_major when it's present, a gadget bump might be all it takes.

Environment

OS: Amazon Linux 2023 (EKS 1.34), kernel 6.12, arm64, containerd 2.2
Version: node-agent v0.3.219 (kubescape-operator chart 1.40.4)

Steps To Reproduce

1. Bind these three rules to a namespace running a busybox pod (sleep as its command):

   - id: TLX901 # control
     expressions:
       message: "'control: ' + event.comm + ' tty=' + string(event.tty)"
       uniqueId: "event.comm + '_' + string(event.pid)"
       ruleExpression:
         - eventType: exec
           expression: 'event.comm == "sh"'
   - id: TLX902
     # same, with expression: 'event.comm == "sh" && event.hasTty'
   - id: TLX903
     # same, with expression: 'event.comm == "sh" && has(event.ttyMajor)'

2. kubectl exec -it <pod> -- sh -c 'tty; sleep 3' → prints /dev/pts/0
3. kubectl exec -it <pod> -- sh -c 'tty; sleep 5' while a pts index is still held → prints /dev/pts/1

Expected behavior

All three rules fire for both shells: each has a terminal (major 136).

Actual Behavior

Additional context

This matches the phase-1 expectations in Test_35_ExecTTYFieldTest (c-pts0=0), and v0.3.231 still pins the same gadget. Our use case is a rule reporting interactive shells that stays quiet for containers whose start command is a shell (sh -c ... in CronJobs). For now we keep a per-workload exception list, which we'd happily drop. Happy to help test a bump. Thanks!