Re: Problem with getting signals delivered to a Samba server

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, Jun 26, 2007 at 04:48:42PM -0400, Robert Rappaport wrote:
> A Samba server running on Linux, supporting Oplocks for its clients,
> will establish a lease for each OpLock that it grants to a client.
> Then when some other activity in the file system occurs, such as
> another application opening a file with an OpLock (and therefore a
> lease), a call is made to Linux routine, __break_lease() and this is
> supposed to result in a signal being delivered to the process which
> established the lease.  Receipt of such a signal should cause the
> process to release the lease.
>
> What I see is that the delivery of such signals appears to be
> unreliable.  The problem occurs in routine, sigio_perm(), which often
> returns a value which then leads to the signal not being delivered.
> The entire sequence of calls leading to this failure is as follows:
>
>    __break_lease() => lease_break_callback() => kill_fasync() =>
> __kill_fasync() => send_sigio() => send_sigio_to_task() =>
> sigio_perm()
>
>  Routine, sigio_perm() is very simple:
>
>  static inline int sigio_perm(struct task_struct *p,
>                              struct fown_struct *fown, int sig)
>  {
>          return (((fown->euid == 0) ||
>                   (fown->euid == p->suid) || (fown->euid == p->uid) ||
>                   (fown->uid == p->suid) || (fown->uid == p->uid)) &&
>                  !security_file_send_sigiotask(p, fown, sig));
> }

Hm.  I don't understand this code well either.  However, looking at the
F_SETOWN description in the man page for fcntl(2):

	"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)."

where the relevant language from kill(2) is:

	"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."

it appears that the above logic is enforcing this requirement.

> And the reason that this is failing to send the signal is that the
> values for fown->euid and fown->uid are both 500, consistent with a
> user mode client, and the values of p->uid and p->suid are both zero,
> consistent with a root process, i.e. the smbd.

So it looks to me like the kernel may be correct here, and that Samba
should be calling F_SETOWN as root to ensure that this permission check
will pass.  (From a quick check of the F_SETOWN implementation in
fs/fcntl.c, it does appear to set the uid and euid to the that of the
calling process, as documented in the man pages.)

--b.