On Tue, Dec 13, 2016 at 09:10:46PM +0100, Lennart Poettering wrote: > 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 expand on this a bit: because of the way those features are implemented (remounting swatches of the file system tree read-only), there's no magic, and no special auditing is necessary: the program gets a normal error (EROFS, EACESS, etc), and should log and handle it in the usual manner. In case this is not enough, strace will do a good job. In many ways, this is easier an more flexible than audit logs. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
