Re: [PATCH v2 0/2] unprivileged fanotify listener

[Amir Goldstein <amir73il@gmail.com>]

> > That may change when systemd home dirs feature starts to use idmapped
> > mounts. Being able to watch the user's entire home directory is a big
> > win already.
>
> Do you mean that home directory would be an extra mount with userns in
> which the user has CAP_SYS_ADMIN so he'd be able to watch subtrees on that
> mount?
>

That is what I meant.
My understanding of the systemd-homed use case for idmapped mounts is
that the user has CAP_SYS_ADMIN is the mapped userns, but I may be wrong.

> > > subtree watches would be IMO interesting to much more users.
> >
> > Agreed.
> >
> > I was looking into that as well, using the example of nfsd_acceptable()
> > to implement the subtree permission check.
> >
> > The problem here is that even if unprivileged users cannot compromise
> > security, they can still cause significant CPU overhead either queueing
> > events or filtering events and that is something I haven't been able to
> > figure out a way to escape from.
>
> WRT queueing overhead, given a user can place ~1M of directory watches, he
> can cause noticable total overhead for queueing events anyway. Furthermore

I suppose so. But a user placing 1M dir watches at least adds this overhead
knowingly. Adding a overhead on the entire filesystem when just wanting to
watch a small subtree doesn't sound ideal. Especially in very nested setups.
So yes, we need to be careful.

> the queue size is limited so unless the user spends time consuming events
> as well, the load won't last long. But I agree we need to be careful not to
> introduce too big latencies to operations generating events. So I think if
> we could quickly detect whether a generated event has a good chance of
> being relevant for some subtree watch of a group and queue it in that case
> and worry about permission checks only once events are received and thus
> receiver pays the cost of expensive checks, that might be fine as well.
>

So far the only idea I had for "quickly detect" which I cannot find flaws in
is to filter by mnt_userms, but its power is limited.

Thanks,
Amir.