Re: Can fanotify OPEN_PERM work with CIFS?

[Jan Kara <jack@suse.cz>]

Hello!

On Thu 07-11-19 17:47:38, Marko Rauhamaa wrote:
> In a common setup, CIFS file access is tied to the credentials of the
> regular Linux user, but the local root has no access. If the local root
> monitors such a CIFS mount point with OPEN_PERM, dentry_open() in
> fs/notify/fanotify/fanotify_user.c fails with EPERM or EACCES depending
> on the kernel version. In effect, the whole mount point becomes
> inaccessible to any user.
> 
> I understand the question has intricate corner cases and security
> considerations, but is the common use case insurmountable? When the
> regular user is opening a file for reading and waiting for a permission
> to continue, must the file be reopened instead of being "lent" to the
> content checker via duping the fd?

I'm sorry for late reply. I've noticed this email only now. It is difficult
to "lend" the fd being opened by the application to the fanotify permission
event. Mainly because by the time the event is generated, that file
descriptor is not open yet - the event gets generated while we are checking
whether open is permitted which is before the "opening act" really happens.
And this is a fundamental thing because open(2) can have various side
effects (like truncating a file). And then there are also other smaller
issues like that different file mode or flags may need to be used for
fanotify event than for the original open.

I don't know details of CIFS permission model but I assume that there's a
similar problem as with NFS with generally untrusted client and thus the
server restricts client access to the authenticated credentials. That is
problematic with fanotify because even if we impersonated original opening
process we needn't be able to open the file with requested mode (think of
client having only read access to a file and fanotify request also write
access). So the permission model of network filesystems is incompatible
with fanotify permission model and I don't see an easy way how to
work-around this :-|.

								Honza

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR