From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49380) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XM9xz-0002iw-0Q for qemu-devel@nongnu.org; Tue, 26 Aug 2014 02:10:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XM9xp-0004Dc-S9 for qemu-devel@nongnu.org; Tue, 26 Aug 2014 02:10:50 -0400 Received: from e28smtp04.in.ibm.com ([122.248.162.4]:39334) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XM9xp-0004DE-A8 for qemu-devel@nongnu.org; Tue, 26 Aug 2014 02:10:41 -0400 Received: from /spool/local by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 26 Aug 2014 11:40:37 +0530 Received: from d28relay05.in.ibm.com (d28relay05.in.ibm.com [9.184.220.62]) by d28dlp01.in.ibm.com (Postfix) with ESMTP id 130DBE0060 for ; Tue, 26 Aug 2014 11:42:47 +0530 (IST) Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay05.in.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s7Q6B06266781424 for ; Tue, 26 Aug 2014 11:41:00 +0530 Received: from d28av03.in.ibm.com (localhost [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s7Q6AXVZ028947 for ; Tue, 26 Aug 2014 11:40:34 +0530 From: "Aneesh Kumar K.V" In-Reply-To: <53FB1AB8.9010806@msgid.tls.msk.ru> References: <53D90245.2050903@msgid.tls.msk.ru> <87k36u3jbv.fsf@linux.vnet.ibm.com> <87egx23fp2.fsf@linux.vnet.ibm.com> <53FB1AB8.9010806@msgid.tls.msk.ru> Date: Tue, 26 Aug 2014 11:40:25 +0530 Message-ID: <87iolfixwu.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] 9p mapped-* security model infos are architecture-specific List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev , Qemu Development List Cc: 755740@bugs.debian.org Michael Tokarev writes: > I haven't noticed this email - which is almost a month old now - until today. > So replying now... > > 30.07.2014 21:43, Aneesh Kumar K.V wrote: >> "Aneesh Kumar K.V" writes: >> >>> Michael Tokarev writes: >>> >>>> Apparently the the mapped-* security models results in a raw bytes >>>> being dumped to host without any architecture normalization (in >>>> host byte order). This may even lead to security issues in guest >>>> when the same files are served from another host for example. >>>> >>>> This bug has been initially submitted against debian qemu package, see >>>> http://bugs.debian.org/755740 >>>> >>> >>> Thanks for reporting the bug. Yes we do have issue with >>> mapped-xattr. But mapped-file should be ok. We record the uid/gid as >>> string in the file. >> >> What would be the best way to fix this in a backward compatible way ? >> Considering most of the users will be little endian host, we could do "always >> store in little endian format" which of-course will break big-endian >> hosts. We could possibly ask them to update xattr using external tools ? > > If there's no way to _detect_ the used format (maybe doing some guessing, -- > if that's possible to do in a reliable way, it should be good), that's > one of 2 possible options as I see it: that or introduce a new format > entirely, maybe with another attribute name. > > It might not be even required to use an external tool for conversion. > Again, if qemu is able to detect "wrong" endiannes, it might just > update things itself, or print a warning and switch to an old format, > or something like that. I was not able to come up with a way to detect "wrong" endianness. > > But the guessing idea might not be as bad really. I haven't looked > closely which information is stored in there, -- but it is possible > that some fields should have zeros in some bytes for example, and > if these aren't zero but becomes zeros after endianness conversion > that might be a good indicator. No, they are 32 bit numbers and we can't make any assumptions w.r.t upper half/lower half being zero > > I'm not sure the runtime code should be able to work with both formats > at the same time. Actually, I'm not sure this is a big issue to > start with -- indeed, you said it already, majority of users of 9pfs > should be little endian hosts, -- are there any big endian hosts > using this, at all? :) How about trying to detect (preferrable at > init time) and refusing to start if old/wrong format is detected. > > Maybe have a compile-time define to use native or little endian > format is a good idea too. > That would confuse further. It also impact the interoperability of export path across different build of qemus. > Bastian, since you discovered this issue, you might be using > a host with "uncommon" endianness, what do you think? > -aneesh