linux-kernel - Re: [PATCH] kdesu broken

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.01.0907280944150.3186@localhost.localdomain>
Date:	Tue, 28 Jul 2009 09:49:14 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
cc:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Ray Lee <ray-lk@...rabbit.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] kdesu broken

On Tue, 28 Jul 2009, Alan Cox wrote:
> 
> We don't ignore it.

Yes we do. Look at Ogawa-san's patch. And read my email answer to it.

> What goes in one end comes out the other after tty
> processing (ldisc, echo etc). Reliably. Both the EOF fix and the
> tty->low_latency fix cure that. [The low latency one also provides the
> *exact* same semantics as we had prior to 2.6.31-rc as well]

I agree that the low-latency thing should fix things, and I applied it. 
But I think that Ogawa's patch is fundamentally "correct" at a much higher 
level. Rather than depend on low-latency being set, it just "Does The 
Right Thing(tm)", by making sure that readers never even look at the EOF 
bits etc until they have flushed the tty ldisc state.

> If I understand Ogawa correctly then what emacs thinks is true is quite
> different: Emacs thinks that
> 
> 	write(pty, "data", length)
> 	close(pty)
> 	exit()
> 
> will always ensure that the other end has already got the data before
> close() completes - or to be more exact before the parent receives SIGCLD.

.. and depending on what emacs does with signals and it's select() loop, 
that may actually be _entirely_reasonable_.

Imagine being in 'select()' (or read, for that matter), and getting EINTR 
due to SIGCHLD. What is the correct expectations?

The correct expectation is that the select() (or read()) should have 
returned any data that it saw _before_ it returns EINTR.

		Linus
--
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/