linux-kernel - Re: Breaking userspace? Re: 3.0.24 broke aufofs on mixed 32/64bit environment

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: <CA+55aFx9hATsnANWYSoagycc2HnXO=5Oa3gtqBjMr9eoe1obpA@mail.gmail.com>
Date:	Tue, 24 Apr 2012 14:01:57 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Thomas Meyer <thomas@...3r.de>
Cc:	Michael Tokarev <mjt@....msk.ru>, Ian Kent <raven@...maw.net>,
	"stable@...nel.org" <stable@...nel.org>, autofs@...r.kernel.org,
	Linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Breaking userspace? Re: 3.0.24 broke aufofs on mixed 32/64bit environment

On Tue, Apr 24, 2012 at 1:42 PM, Thomas Meyer <thomas@...3r.de> wrote:
>
> It broke the autofs feature of systemd (32bit) on a 64bit kernel, which
> resulted in an endless wait in the boot process. I don't use the autofs
> tools. I guess the fix in the autofs package to compensate the kernel
> bug, which has now been fixed, breaks the autofs package.
> The fix in the kernel makes systemd work correctly.

Oh damn, I'd forgotten the details. Ok.

That does mean that we probably just have to do a kernel command line
option for this. And then the autofs4 code that currently does

    sbi->compat_daemon = is_compat_task();

needs to change that to take the command line option into account too.

We could make it a mount option, but since the whole point is that we
want to be compatible with existing binaries that don't *use* special
mount options, I suspect the only reasonable point is at the kernel
command line.

That is, unless somebody can figure out a way to auto-detect how big
the user space read is. The problem with that really is that the
autofs read() system call isn't done directly to some "real autofs"
file descriptor, autofs literally is using the standard pipe code.

So the code in fs/pipe.c does actually see the size of the read. But
the code in fs/autofs4/ does not. And we can't change the interface,
because the whole pipe is opened in user space iirc.

Ugly.

Anybody willing to write the patch?

                 Linus

Damn.
--
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/