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]
Date:	Wed, 18 Apr 2012 00:16:50 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	carlos@...temhalted.org
Cc:	mtk.manpages@...il.com, netdev@...r.kernel.org,
	penguin-kernel@...ove.sakura.ne.jp, linux-api@...r.kernel.org,
	yoshfuji@...ux-ipv6.org, jengelh@...ozas.de, w@....eu,
	alan@...rguk.ukuu.org.uk
Subject: Re: [patch] Fix handling of overlength pathname in AF_UNIX sun_path

From: "Carlos O'Donell" <carlos@...temhalted.org>
Date: Wed, 18 Apr 2012 00:08:47 -0400

> I don't clearly understand your position here, and perhaps that's my
> own ignorance, but could you please clarify, with examples, exactly
> why the change is not acceptable?

My position is that since millions upon millions of Linux systems, in
fact every single Linux system, exists right now with the current
behavior we are not helping application writers at all by changing
behavior now after it's been this way for nearly 20 years.

Because if an application writer wants his code to work on systems
that actually exist he has to accomodate the non-NULL termination
situation if he wants to inspect or print out an AF_UNIX path.

Because every system in existence right now allows the non-NULL
terminated AF_UNIX paths, therefore it's possible on every system
in existence right now.

Catch my drift?

The very thing the patch claims to help, it doesn't.  We install this
kernel patch now and then tell application writers that they can just
assume all AF_UNIX paths are NULL terminated when they want to print
it out, because such code will not actually be guarenteed to work on
all deployed Linux machines out there.

You cannot just ignore 20 years of precedence and say "oh let's change
this in the kernel now, and that way application writers don't have to
worry about that lack of NULL termination any more."  It simply
doesn't work like that.

All of this talk about whether applications actually create non-NULL
terminated AF_UNIX paths don't even factor into the conversation.

So the value proposition for this patch simply does not exist.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ