linux-kernel - Re: [patch 0/3] add rt_tgsigqueueinfo syscall [RESEND]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.0902262311350.9135@localhost.localdomain>
Date:	Thu, 26 Feb 2009 23:13:33 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	mtk.manpages@...il.com
cc:	LKML <linux-kernel@...r.kernel.org>,
	Roland McGrath <roland@...hat.com>,
	Oleg Nesterov <oleg@...sign.ru>, Ingo Molnar <mingo@...e.hu>,
	Linux API <linux-api@...r.kernel.org>
Subject: Re: [patch 0/3] add rt_tgsigqueueinfo syscall [RESEND]

Michael,

On Fri, 27 Feb 2009, Michael Kerrisk wrote:
> I haven't looked at this iteration of the patch, to check if it is
> different from the version you posted a few months ago.  I assume it
> isn't different, since you didn't mention any differences.  In that
> case, there are still the questions I raised back then, so I'll just
> repeat them now.

Right, no fundamental changes.
 
> Back in October, I did some testing of this interface.  Two potential
> issues that I saw, both of which relate to inconsistencies with
> rt_sigqueueinfo():
> 
> 1) With rt_siqueueinfo(), we can get the PID (TGID) of the sender,
> which enables the receiver of the signal to know who the sender was,
> and perhaps use that information to (for example) send a signal in the
> other direction.
> 
> With rt_tgsigqueueinfo(), we don't quite have that ability: all that
> the receiver gets is the TGID of the sender, not the TID.  This means
> that we can't (for example) send a signal back to the precise thread
> that signaled us. I'm not sure if this matters or not (but perhaps it
> might when sender and receiver are in the same process?).  I'm also
> not sure whether we want to do anything about this (i.e., extending
> siginfo_t to include a si_tid field), but I wanted to point out this
> assymetry w.r.t. to rt_sigqueueinfo(), in case you had not considered
> it.
> 
> 2) With rt_sigqueueinfo(), we can specify the si_pid and and si_uid
> fields that should be sent to the receiver.  This is not possible with
> rt_tgsigqueueinfo(), which always supplied the caller';s PID and UID
> in the si_pid and si_uid fields sent to the receiver.  See the
> following, created using my test programs below (the 111 & 222
> arguments to t_*sigqueueinfo set the si_pid and si_uid fields in the
> siginfo_t given to the *sigqueueinfo() syscall):

I can see your concern, but I have no strong opinion in either
direction. 

Roland ??

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/