Thread (33 messages) 33 messages, 3 authors, 2021-03-28

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

From: Amir Goldstein <amir73il@gmail.com>
Date: 2021-03-18 17:07:50
Also in: linux-fsdevel

quoted
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.
quoted
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help