On Mi, 08.04.20 20:58, Andy Pieters (systemd@xxxxxxxxxxxxxxxxx) wrote: > Hi list > > I'm trying to satisfy PCI requirements by having on-access virus > scanning on servers involved with card-holder data. > > Normally we could use clamav which has got on-access scanning, but > this has been removed > > Could we get systemd to help out by using its fanotify start a unit to > scan an object > > I'm just thinking out loud here but is it possible to have a wildcard > path unit? then drill down on the exact reason > > No I'm probably thinking about it the wrong way > > Any thoughts from the list please? So there has been a TODO list item about adding fanotify support to .path units, since fanotify can do some interesting things that inotify can't. Howevre, this is mostly the async stuff in fanotify. For the anti-virus stuff you'd need the sync stuff in fanotify, i.e. where fs access hangs until the fanotify-used program acknowledges it. I doubt this would fit into the .path unit concept, which is very asynchronous, very "coalescing" in behaviour. i.e. a mechanism where every individual request needs to be ack'ed doesn't fit into it. Behaviour like that probably would probably fit better into the .socket concept, which actually is about more than just pure sockets, it already can listen on FIFOs, msgqs, USB functions and and "special files". Maybe a ListenFileAccessNotify= could be added that does what you need. This would then mean that PID 1 would establish the fanotify watch, and wait for POLLIN on it, and as soon as that happens fork off some service and pass the fanotify fd to it. The service would have to read the event off it and acknowledge it. It could then exit after a while. Would that work for you? If so, prep a PR and submit it, would be happy to review it. Lennart -- Lennart Poettering, Berlin _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel