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]

Date:	Wed, 18 Apr 2012 08:57:58 -0400
From:	"Carlos O'Donell" <carlos@...temhalted.org>
To:	David Miller <davem@...emloft.net>
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

On Wed, Apr 18, 2012 at 12:16 AM, David Miller <davem@...emloft.net> wrote:
> 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.

Thank you, this is the kind of position statement I can point to if I
ever get asked about this again.

In summary your opinion is that the API has and always will allow up
to 108 chars to be used in sun_path?

In which case I will talk to the Austin group to get a good example
added to POSIX showing safe usage.

Cheers,
Carlos.
--
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