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.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
