Issues with Linux kernel oplocks
J. Bruce Fields
bfields at fieldses.org
Tue Jul 23 14:44:59 MDT 2013
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
But we don't want somebody else to be able to do that "opt in" step for
More information about the samba-technical