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
| ||
|
Date: Sat, 25 Jul 2009 12:48:59 +0100 From: Alan Cox <alan@...rguk.ukuu.org.uk> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: "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: [Regression] kdesu broken > > I don't know where you got that idea from. Avoiding breaking user space > > unneccessarily is good but if its buggy you often can't do anything about > > it. > > Alan, he got that idea from me. > > We don't do regressions. If user space depended on old behavior, we don't > change behavior I think there are two bugs being confused here. The first kdesu bug isn't the EIO one. It's just busted userspace code that happened to be lucky. It's also impossible to keep that "luck" going. The other problem is the EIO - which is a bug. > And regardless of that, I do not think EIO is the right thing to return at > all. If the other side of a pty went away, return 0 and possibly send a > HUP, or whatever. What did we do before? If the other side of a pty goes away we send SIGHUP and at that point return -EIO as required by POSIX, SuS and various other things. You cannot return "EOF" as that means the user caused an EOF event (eg hit ^D). There is a bug going on here (the one that bites emacs meta-whatever compile) where you get an -EIO and that seems to be timing related due to flushing. I'm currently working on that one. I suspect we will need to make the close on the writer wait for the data to be flushed through the reader side and I'm testing some fixes for that. So there are two things here that need not to be muddled up: 1. Case where kdesu from logging what is going on and code inspection does: read not what I wanted discard the lot read oh damn I missed the bit I wanted If we go back to the old pty approach we break ppp, locking rules and everything else, and re-introduce DoS attacks (and some worse ones) going back to 2.0 if not earlier. 2. A case where previously it happened that write(pty, "Wibble", 6); close(pty); would *usually* block on close until the "Wibble" was consumed the other end. (ie logically speaking the buffering is on the writer not the reader) We can implement that (although probably a timeout to avoid certain deadlocks is needed) I plan to fix #2 but not #1. There really isn't any way to keep #1 true. Although the spec has nothing to say about #2 every implementation I've you get the wibble reliably and we used to, so it needs fixing. Alan -- 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/
Powered by blists - more mailing lists