linux-kernel - Re: [PATCH v2] Introduce a version6 of autofs interface, to fix design error.

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: <CANXojcy2CinBrBY2+ZRoD_4PzZDj5dELsaa57_byQpwmmHpk+g@mail.gmail.com>
Date:	Fri, 27 Apr 2012 22:13:39 +0200
From:	Stef Bon <stefbon@...il.com>
To:	autofs@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] Introduce a version6 of autofs interface, to fix
 design error.

I do not have any solution to the issue discussed here, but mentioned
is that automount and systemd are the only packages using autofs. I'm
thinking about creating a FUSE filesystem which will make use of
autofs (direct) mounting, where the FUSE fs will do something what now
automount does.  Indirect mounts are not necessary anymore, the
browsable maps will be created in the FUSE fs.

Stef Bon

2012/4/27 Linus Torvalds <torvalds@...ux-foundation.org>:
> On Fri, Apr 27, 2012 at 12:24 PM, David Miller <davem@...emloft.net> wrote:
>>
>> If you can pull that off, it would certainly work and be the best
>> solution.
>>
>> BTW, this has happened before, we had this same problem passing data
>> over netlink sockets.  And since it's packetized already we had a
>> slightly easier time dealing with it.
>
> Ok, so here's a fairly quick hack.
>
> NOTE! I haven't actually tested this, because I don't use autofs
> (well, not knowingly - maybe I have a machine that actually does).
>
> What it does is add a new "packetized" flag to pipes, which does two
> simple things:
>  - do not merge write data in pipe buffers when writing
>  - when reading, consider a pipe buffer to be "spent" when any of the
> data has been read
>
> Of course, if you write more than PIPE_BUFFER bytes, the packetization
> doesn't work, but hey, if you do that, it's your own damn problem.
>
> Then, this just makes (for debugging!) autofs always write eight extra
> bytes of garbage (NOTE NOTE NOTE! This will write uninitialized data,
> so this is literally just for debugging this particular issue), so
> that if the whole "kernel writes a few bytes extra" approach with pipe
> packetization doesn't work, you would see it even on native 32-bit or
> 64-bit mode, without having to even test the special case of "32-bit
> automount binary on a 64-bit kernel". So *anybody* who uses autofs can
> test this patch and see if autofs still works for them despite the
> extra padding on the write.
>
> So note the "+8" in autofs_v5_packet_size(). It's there on purpose,
> but it needs to be removed for actual final results if this works for
> testing.
>
> Comments? The patch looks fairly simple. The "packetized pipe" might
> even be useful for other users and maybe we might want to expose it as
> an actual pipe fcntl, but right now the only thing that sets that flag
> is autofs.
>
> Does this even work? I might well have missed some obvious thing, this
> was put together pretty quickly, but I think the *concept* may be the
> right approach to this whole mess.
>
> (And yes, we could probably just pack the "struct pipe_inode_info"
> better. We don't really need 32 bits for the pipe writer count etc.
> But to make the patch simple, I just added a whole new bitfield, which
> will just grow that silly structure).
>
>                       Linus
--
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/