Since 2.2.0, opening /dev/ppp (char major 108) fails with EPERM inside machines — even as root, even in a --privileged container. /dev/net/tun is unaffected. This breaks pppd/openfortivpn; worked on 2.1.3.
Repro (no VPN needed):
docker run --rm --privileged alpine sh -c \
'mknod /dev/ppp c 108 0 2>/dev/null; (exec 3<>/dev/ppp) && echo OK || echo EPERM'
- 2.1.3 (20115, kernel 7.0.5) →
OK
- 2.2.1 (20628, kernel 7.0.11) →
EPERM
mknod succeeds but the open is denied — looks like the cgroup v2 device allowlist dropped major 108. Plausibly the 2.2.0 "Security improvements to the kernel" change.
Confirms the VPN break: standalone pppd on 2.2.1 prints Couldn't open the /dev/ppp device: Operation not permitted / Sorry - this system lacks PPP kernel support, exit 4 — matching openfortivpn's log exactly. Fine on 2.1.3.
Env: macOS 26.5.1, Apple Silicon.
Ask: re-allow /dev/ppp (or make it opt-in, like tun)? Workaround: downgrade to 2.1.3, or use a tun-based client (FortiClient / openconnect --protocol=fortinet).
Since 2.2.0, opening
/dev/ppp(char major 108) fails withEPERMinside machines — even as root, even in a--privilegedcontainer./dev/net/tunis unaffected. This breakspppd/openfortivpn; worked on 2.1.3.Repro (no VPN needed):
docker run --rm --privileged alpine sh -c \ 'mknod /dev/ppp c 108 0 2>/dev/null; (exec 3<>/dev/ppp) && echo OK || echo EPERM'OKEPERMmknodsucceeds but the open is denied — looks like the cgroup v2 device allowlist dropped major 108. Plausibly the 2.2.0 "Security improvements to the kernel" change.Confirms the VPN break: standalone
pppdon 2.2.1 printsCouldn't open the /dev/ppp device: Operation not permitted/Sorry - this system lacks PPP kernel support, exit 4 — matching openfortivpn's log exactly. Fine on 2.1.3.Env: macOS 26.5.1, Apple Silicon.
Ask: re-allow
/dev/ppp(or make it opt-in, like tun)? Workaround: downgrade to 2.1.3, or use a tun-based client (FortiClient /openconnect --protocol=fortinet).