Issues with Linux kernel oplocks

[Jeremy Allison]

On Tue, Jul 23, 2013 at 05:08:53PM -0400, J. Bruce Fields wrote:
> 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.

No, we set both euid and real uid (if possible on the platform). We only
leave the save-set uid alone.

Jeremy.