On Thu, Nov 26, 2020 at 1:10 PM Jan Kara <jack@xxxxxxx> wrote: > > On Wed 25-11-20 14:34:16, Amir Goldstein wrote: > > On Wed, Nov 25, 2020 at 1:01 PM Jan Kara <jack@xxxxxxx> wrote: > > > In fact I was considering for a while that we could even make subtree > > > watches completely unpriviledged - when we walk the dir tree anyway, we > > > could also check permissions along the way. Due to locking this would be > > > difficult to do when generating the event but it might be actually doable > > > if we perform the permission check when reporting the event to userspace. > > > Just a food for thought... > > > > Maybe... but there are some other advantages to restricting to mount. > > > > One is that with btrfs subvolumes conn->fsid can actually cache the > > subvolume's fsid and we could remove the restriction of -EXDEV > > error of FAN_MARK_FILESYSTEM on subvolume. > > I'm not sure I understand this - do you mean we could support > FAN_MARK_FILESYSTEM_SUBTREE on btrfs subvolumes? I agree with that. I'm Yes, that's what I meant. > just not sure how subtree watches are related to general > FAN_MARK_FILESYSTEM marks on btrfs... > I thought that it would solve the ambiguity issue with btrfs fsid (it differs for objects inside a subvolume), because conn->fsid of subtree would cache the subvolume's fsid, but if there are both a filesystem mark and subtree mark on a subvolume, that would result in ambiguity again, so we are still not out of the woods. If this hand waving wasn't clear, don't worry about it. I will think about it some more and document the issue in my next post. Thanks, Amir.
