On Tue, 13.12.16 15:02, Przemek Klosowski (przemek.klosowski@xxxxxxxx) wrote: > On 12/13/2016 02:51 PM, Lennart Poettering wrote: > > Yeah, this is really what it boils down to: the goal with the systemd > > directives is to make things easy to grok and easy to change. I can > > probably explain to most Linux admins who have administered a current > > Fedora in 5min what ProtectSystem=strict and > > ReadWritePaths=/var/lib/myservice does, and why it's a good thing. And > > One thing that SELinux does right is auditing---access violations are > logged, so that there are no silent mysterious failures (well, mumble, > mumble, maybe sometimes, you know what I mean). Also, SELinux allows > debugging in the permissive mode that just logs without actually blocking > access. What happens after systemd directives result in denials? There's no auditing hook-up with systemd's sandboxing options. The precise error your service gets depends on the sandboxing setting: ProtectSystem=strict makes file systems read-only for a service, and hence will result in EROFS if it tries to access something. The seccomp-based settings by default result in EPERM. > BTW, it's ProtectSystem=true/false/full (not strict), right? ProtectSystem=strict is a v232 addition (→ rawhide). It's stricter than "full" even... Lennart -- Lennart Poettering, Red Hat _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
