On 04/27/2012 04:07 PM, Linus Torvalds wrote: > > The important change is actually to make the read return the size requested. > > So broken user space does a read() with the wrong size - and then > checks that it gets *exactly* that many bytes. Not more, not less. > > The way to handle that is to > - make sure the kernel always writes the maximally padded data > - make the packetization simply drop any data that was in the packet > that the reader didn't ask for. > > This is very much a semantic change, in that any client that tries to > read the packet with multiple reads (one 4-byte read to see the size, > followed by one "right-sized" read of the data) would be totally > screwed. The first read would indeed read the size, but it also - > because of the packetized interface - would simply drop the data, and > the next read would read the first bytes of the next packet. > > But that's not what the autofs users actually do anyway. They just > read the whole packet. So we can make *them* work. And the new > interface will be fairly robust (in fact, you could pass it some big > buffer and just know you always get exactly one packet, and never have > that whole stupid "sizeof()" at all). > OK, I follow you now. That would work for autofs; I presume it is not something we would export to other users though? If so I'd worry about opening up new security issues. Still, I have to admit... we have a grand total of three users of this interface as far as we know (autofs, systemd, and am-utils if they ever revved that one to v5.) Would it really not be better to do the zero-eating user space fix? -hpa -- To unsubscribe from this list: send the line "unsubscribe autofs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
