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@xxxxxxxx> SUSE Labs, CR
