Issues with Linux kernel oplocks

[J. Bruce Fields]

On Tue, Jul 23, 2013 at 02:06:04PM +0200, Ralph Wuerthner wrote:
> Hi,
> 
> we identified an interesting defect with Samba and Linux kernel oplocks:
> 
> Having Samba granted an oplock on a file to a CIFS client. Next a
> regular user space application running on the Samba system is trying
> to access the same file too. The regular procedure would be that the
> kernel sends a signal to the Samba process holding the kernel lease
> for this file. Samba would receive the signal and inform the CIFS
> client about the lease break and after receiving the client response
> return the lease for the file.
> 
> Unfortunately in our tests the Linux kernel does not always send the
> signal to the Samba process. It turned out that the kernel compares
> in sigio_perm() the lock/lease owner (fown) euid/uid with the
> thread's suid/uid who needs to receive the signal. If they don't
> match, no signal will be send. Because Samba is switching its uids
> back and forth this compare might fail and the signal will be not
> send.
> 
> In our particular tests Samba is requesting the lease with uid
> 11000500, making uid 11000500 the owner of the lease. If Samba is
> running as root when the signal comes the compare fails, the signal
> is not send and Samba cannot release the lease.
> 
> Any idea what would be the rational of this behaviour in the Linux
> kernel? Has somebody seen this before?

>From 'man 2 fcntl':

	Sending a signal to the owner process (group) specified by
	F_SETOWN is subject to the same permissions checks as are
	described for kill(2), where the sending process is the one that
	employs F_SETOWN (but see BUGS below).

And 'man 2 kill':

	For a process to have permission to send a signal it must either
	be privileged (under Linux: have the CAP_KILL capability), or
	the real or effective user ID of the sending process must equal
	the real or saved set-user-ID of the target process.

I'm not sure what exactly the threat is here.  (An unprivileged process
being able to trigger a signal to a privileged process sharing the same
file descriptor?)  In any case it's clearly intentional.

At the time you set up the oplock, couldn't you use F_SETOWN to direct
oplock-break signals to some dedicated thread that doesn't change uid?

--b.