Issues with Linux kernel oplocks
J. Bruce Fields
bfields at fieldses.org
Tue Jul 23 13:35:12 MDT 2013
On Tue, Jul 23, 2013 at 02:06:04PM +0200, Ralph Wuerthner wrote:
> 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
> 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?
More information about the samba-technical