Re: [PATCH v2 18/20] fsnotify: send path type events to group with super block marks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 19, 2018 at 4:49 PM, Jan Kara <jack@xxxxxxx> wrote:
> On Thu 05-04-18 16:18:19, Amir Goldstein wrote:
>> Send events to group if super block mark mask matches the event
>> and unless the same group has an ignore mask on the vfsmount or
>> the inode on which the event occurred.
>>
>> Soon, fanotify backend is going to support super block marks and
>> fanotify currently only supports path type events.
>>
>> Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
>
> So what I miss in this patch set is a description (manpage style) of what
> is the desired semantics of the new functionality. Then also what usecases
> motivate this. Probably this belongs to the initial patch. Also linux-api
> should be CCed as this is a new API so it should get wider scrutiny.
>
> Also I'm somewhat concerned with the security of superblock marks - sure
> fanotify is currently guarded by CAP_SYS_ADMIN but that seriously limits
> its usefulness so long-term we might need to get rid of that at least for

My long term goal is for fanotify to be a super set of inotify, so that is part
of the plan. The easiest way would be to introduce fanotify_init() flags that
hide all the information in the fanotify event that is sensitive and
allow unprivileged
user to setup a file/dir watch according to same permission ruled of inotify.

> some subset of the functionality or at least relieve that to CAP_SYS_ADMIN
> inside current namespace. And I'm not sure superblock marks are safe even
> for CAP_SYS_ADMIN process in the current namespace as the process could
> escape from its current mount namespace by that. But maybe I'm wrong.

IMO, setup of super block watch should require same permissions as mount of
block device, so if fs has no FS_USERNS_MOUNT flag, only root ns admin should
be able to setup a super block watch and then there is no issue with security.

> I'll try to extract more knowledge about this from some guys at LSF/MM...

Yeh, let's do that.
I have a 30 minute slot for "persistent change journal", I will start with
a 5 min overview of super block watch roadmap to see if there are any
objections.

Thanks,
Amir.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux