User=0day considered harmful in systemd

It's reasonable to expect that if you explicitly go to the trouble of specifying a user for a unit that isn't root, that unit won't inadvertently – and silently – be executed as root. This is not a backwards-compatibility issue since Unix has supported different users from the very start. I'm not as convinced that directives controlling new(ish) security features should automatically lead to hard errors on older systems that don't offer these features at all; perhaps emitting very obvious warnings that SELinux or AppArmor is not supported on this system and that therefore these features cannot be enabled is the reasonable tradeoff here, just so the administrator knows what to expect. It depends.

What certainly should not happen at all, ever, is that important and ubiquitous security settings are silently ignored (or ignored with a generic warning) because systemd doesn't like a given configuration value. Arguably an error message such as “invalid username ‘0day’, using ‘root’ instead” would have called attention to the situation being discussed here, where silently falling back to root is an obviously bad idea no matter what distribution you're using and whether you're in the past, present, or future.