`ssdd` command needs `ptrace` syscall

[locnnil]

Seccomp log:

= Seccomp =
Time: Jun 13 22:53:41
Log: auid=1000 uid=0 gid=0 ses=3 subj=snap.rt-tests.ssdd pid=1828190 comm="ssdd" exe="/snap/rt-tests/6/usr/bin/ssdd" sig=0 arch=c000003e 101(ptrace) compat=0 ip=0x752d587ae0fd code=0x50000
Syscall: ptrace

ssdd aplication output:

$ sudo ssdd --iters=3 --quiet
forktest#0/16916: EXITING, ERROR: attach failed.  errno 1
forktest#3/16921: EXITING, ERROR: attach failed.  errno 1
forktest#4/16923: EXITING, ERROR: attach failed.  errno 1
forktest#2/16919: EXITING, ERROR: attach failed.  errno 1
forktest#9/16933: EXITING, ERROR: attach failed.  errno 1
forktest#8/16930: EXITING, ERROR: attach failed.  errno 1
forktest#1/16917: EXITING, ERROR: attach failed.  errno 1
forktest#6/16927: EXITING, ERROR: attach failed.  errno 1
forktest#5/16925: EXITING, ERROR: attach failed.  errno 1
forktest#7/16928: EXITING, ERROR: attach failed.  errno 1
One or more tests FAILED.

[locnnil]

Since the system-observe snapd interface explicitly has a seccomp rule to deny this syscall, it's unlikely that it can run in a confined way using another interface.

[locnnil]

Seems that snapd really wants to suppress ptrace at all costs.

On snap-confine app, the daemon responsible to apply all the Seccomp and AppArmor rules, it's explicitly said that:

'ptrace (trace)' are blocked by AppArmor with typical snapd interfaces.

[locnnil]

Conclusion

• Nowadays ssdd only works if rt-tests is installed in devmode.

For installing in devmode:

sudo snap install rt-tests --edge --devmode