[systemd-devel] systemd && fanotify / path activation

[Lennart Poettering]

On Mi, 08.04.20 20:58, Andy Pieters (systemd at andypieters.me.uk) 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