Michael Tokarev <m...@tls.msk.ru> 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" <aneesh.ku...@linux.vnet.ibm.com> writes: >> >>> Michael Tokarev <m...@tls.msk.ru> 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
