Issues with Linux kernel oplocks

J. Bruce Fields bfields at fieldses.org
Tue Jul 23 15:08:53 MDT 2013


On Tue, Jul 23, 2013 at 05:01:15PM -0400, J. Bruce Fields wrote:
> On Tue, Jul 23, 2013 at 01:47:30PM -0700, Jeremy Allison wrote:
> > On Tue, Jul 23, 2013 at 04:32:16PM -0400, J. Bruce Fields wrote:
> > > 
> > > 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.)
> > 
> > Ok then I'm really confused. Samba always does
> > the lease set as the same uid as the open, we
> > never change uids between the open and the
> > setting of the kernel oplock.
> 
> Right, so both are done with uid X.  But then later when the lease break
> happens the signal is sent to the thread that did the open.  And that
> signal is treated as if it's coming from uid X.  The thread may have
> changed uid's, and that may not work.
> 
> (OK, "uid" isn't quite right, see the kill(2) language for the actual
> uid's involved.)

But actually, I don't understand this part: Samba's normally only
changing the euid or fsuid, not the real uid, right?  In which case I'd
think the real uid's would always agree and by the above language the
signal would always be permitted.

--b.


More information about the samba-technical mailing list