Problem with getting signals delivered to a Samba server

Problem with getting signals delivered to a Samba server

[Robert Rappaport]

I have been working for a while on making a distributed file system
that runs on Linux to become "lease aware".  I have been using
advanced versions of proposed Linux modifications that allow a file
system to have a "setlease" file operations method.  My primary focus
in this work was to allow Samba OpLocks to function properly with my
file system.

 I have been using a version of Linux-2.6.19 that I modified to add
the lease support.

 In the course of this work I have run up against what appears to be a
Linux problem that prevents the delivery of a signal to the Samba
server.

 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));
 }

 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.

 Being a relative neophyte in these questions, I am not sure what the
above code is trying to prevent.  However for my purposes I achieved
behavior that I could live with by modifying the above in the
following way:

  static inline int sigio_perm(struct task_struct *p,
                              struct fown_struct *fown, int sig)
   {
           return (((fown->euid == 0) || (p->suid == 0) || (p->uid == 0) ||
                    (fown->euid == p->suid) || (fown->euid == p->uid) ||
                    (fown->uid == p->suid) || (fown->uid == p->uid)) &&
                   !security_file_send_sigiotask(p, fown, sig));
 }

 That is, I added  "(p->suid == 0) || (p->uid == 0) ||" to the set of
conditions to be tested.  I am not sure of the side-effects that this
might cause, but for me at least, this resolved my immediate problem.

 I would appreciate it if someone more knowledgeable could comment on
this and possibly look into what apears to be a problem.

 - Robert Rappaport

Re: Problem with getting signals delivered to a Samba server

[J. Bruce Fields]

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.