Issues with Linux kernel oplocks

[J. Bruce Fields]

On Tue, Jul 23, 2013 at 04:32:16PM -0400, J. Bruce Fields wrote:
> On Tue, Jul 23, 2013 at 01:25:52PM -0700, Jeremy Allison wrote:
> > On Tue, Jul 23, 2013 at 03:35:12PM -0400, J. Bruce Fields wrote:
> > > 
> > > >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.
> > 
> > But that is *clearly* a bug w.r.t. leases. The whole point of
> > leases is that if a process running under uid 123 opens a file and requests a lease,
> > when a process owned by uid 345 tries to open that file then the original process
> > *must* get a signal.
> 
> Sure, but...
> 
> > Neither process has to be privileged, neither
> > process has to have changed uids.
> > 
> > For leases to work this condition:
> > 
> > "the real or effective user ID of the sending process must equal
> > the real or saved set-user-ID of the target process."
> > 
> > cannot be correct. Else you could only break leases between
> > processes who are owned by the same uid - or from a privileged
> > opener.
> 
> ... you're confusing the lease-breaker and the lease-setter.
> 
> Note in the first quote above, "where the sending process is the one
> that employs F_SETOWN".  (Or equivalently, I think, F_SETLEASE.)

So in other words the idea is that normally somebody else has to be
priviled to send you a signal.

Leases and asynchronous IO change that: now action by anyone could
result in your getting a signal.

But that's OK because you opted into this behavior by using F_SETLEASE
or O_ASYNC.

But we don't want somebody else to be able to do that "opt in" step for
you.

--b.