netdev - Re: [patch] Fix handling of overlength pathname in AF_UNIX sun

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: <20120418.001650.1042781402985153056.davem@davemloft.net>
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