Commit Graph

8 Commits

Author SHA1 Message Date
Chen Gang
4fa4ce7107 hw/9pfs: use g_strdup_printf() instead of PATH_MAX limitation
When path is truncated by PATH_MAX limitation, it causes QEMU to access
incorrect file. So use original full path instead of PATH_MAX within
9pfs (need check/process ENOMEM for related memory allocation).

The related test:

 - Environments (for qemu-devel):

   - Host is under fedora17 desktop with ext4fs:

     qemu-system-x86_64 -hda test.img -m 1024 \
       -net nic,vlan=4,model=virtio,macaddr=00:16:35:AF:94:04 \
       -net tap,vlan=4,ifname=tap4,script=no,downscript=no \
       -device virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=hostshare \
       -fsdev local,security_model=passthrough,id=fsdev0,\
         path=/upstream/vm/data/share/1234567890abcdefghijklmnopqrstuvwxyz\
           ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890acdefghijklmnopqrstuvwxyz\
           ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890/111111111111111111111111111\
           1111111111111111111111111111111111111111111111111111222222222222\
           2222222222222222222222222222222222222222222222222222222222222222\
           2222222222222222222222222222222222233333333333333333333333333333\
           3333333333333333333333333333333333

    - Guest is ubuntu12 server with 9pfs.

      mount -t 9p -o trans=virtio,version=9p2000.L hostshare /share

    - Limitations:

      full path limitation is PATH_MAX (4096B include nul) under Linux.
      file/dir node name maximized length is 256 (include nul) under ext4.

 - Special test:

    Under host, modify the file: "/upstream/vm/data/share/1234567890abcdefg\
      hijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890acdefghijklmno\
      pqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890/111111111111111111111\
      111111111111111111111111111111111111111111111111111111111122222222222\
      222222222222222222222222222222222222222222222222222222222222222222222\
      222222222222222222222222222222233333333333333333333333333333333333333\
      3333333333333333333333333/4444444444444444444444444444444444444444444\
      444444444444444444444444444444444444444444444444444444444444444444444\
      444444444444444444444444444444444444444444444444444444444444444444444\
      444444444444444444444444444444444444444/55555555555555555555555555555\
      555555555555555555555555555555555555555555555555555555555555555555555\
      555555555555555555555555555555555555555555555555555555555555555555555\
      555555555555555555555555555555555555555555555555555555555555555555555\
      55555555/666666666666666666666666666666666666666666666666666666666666\
      666666666666666666666666666666666666666666666666666666666666666666666\
      666666666666666666666666666666666666666666666666666666666666666666666\
      666666666666666666666/77777777777777777777777777777777777777777777777\
      777777777777777777777777777777777777777777777777777777777777777777777\
      777777777777777777777777777777777777777777777777777777777777777777777\
      77777777777777777777777777777777777777777777777777777777777/888888888\
      888888888888888888888888888888888888888888888888888888888888888888888\
      888888888888888888888888888888888888888888888888888888888888888888888\
      888888888888888888888888888888888888888888888888888888888888888888888\
      888888888/99999999999999999999999999999999999999999999999999999999999\
      999999999999999999999999999999999999999999999999999999999999999999999\
      999999999999999999999999999999999999999999999999999999999999999999999\
      99999999999999999999999999999999999999999/000000000000000000000000000\
      000000000000000000000000000000000000000000000000000000000000000000000\
      000000000000000000000000000000000000000000000000000000000000000000000\
      000000000000000000000000000000000000000000000000/aaaaaaaaaaaaaaaaaaaa\
      aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
      aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
      aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbbbbbbbbbbbbbbb\
      bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\
      bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\
      bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb/ccccccccc\
      ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc\
      ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc\
      ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc\
      cccccccccc/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddd\
      ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd\
      ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd\
      dddddddddddddddddddddd/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee\
      eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee\
      eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee\
      eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee/fffffffffffffff\
      fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\
      fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\
      ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff/gggggggggg\
      ggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg\
      ggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg\
      ggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg\
      ggggggggggggggggggggggg/iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii\
      iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii\
      iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii\
      iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii/jjjjjjjjjjjjj\
      jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj\
      jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj/ppppppppppppppppppppp\
      ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp\
      ppppppppppppppppppppppppppppppppppppppp/test1234567890file.log"
        (need enter dir firstly, then modify file, or can not open it).

   Under guest, still allow modify "test1234567890file.log" (will generate
   "test123456" file with contents).

   After apply this patch, can not open "test1234567890file.log" under guest
   (permission denied).

 - Common test:

   All are still OK after apply this path.

     "mkdir -p", "create/open file/dir", "modify file/dir", "rm file/dir".
     change various mount point paths under host and/or guest.

Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
2014-03-04 00:57:57 +05:30
Daniel P. Berrange
8af0020544 hw/9pfs: Fix errno value for xattr functions
If there is no operation driver for the xattr type the
functions return '-1' and set errno to '-EOPNOTSUPP'.
When the calling code sets 'ret = -errno' this turns
into a large positive number.

In Linux 3.11, the kernel has switched to using 9p
version 9p2000.L, instead of 9p2000.u, which enables
support for xattr operations. This on its own is harmless,
but for another change which makes it request the xattr
with a name 'security.capability'.

The result is that the guest sees a succesful return
of 95 bytes of data, instead of a failure with errno
set to 95. Since the kernel expects a maximum of 20
bytes for an xattr return this gets translated to the
unexpected errno ERANGE.

This all means that when running a binary off a 9p fs
in 3.11 kernels you get a fun result of:

  # ./date
  sh: ./date: Numerical result out of range

The only workaround is to pass 'version=9p2000.u' when
mounting the 9p fs in the guest, to disable all use of
xattrs.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2013-10-05 13:05:28 +04:00
Paolo Bonzini
0d09e41a51 hw: move headers to include/
Many of these should be cleaned up with proper qdev-/QOM-ification.
Right now there are many catch-all headers in include/hw/ARCH depending
on cpu.h, and this makes it necessary to compile these files per-target.
However, fixing this does not belong in these patches.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-04-08 18:13:10 +02:00
Jim Meyering
9238c2099d virtio-9p: avoid unwarranted uses of strncpy
In all of these cases, the uses of strncpy were unnecessary, since
at each point of use we know that the NUL-terminated source bytes
fit in the destination buffer.  Use memcpy in place of strncpy.

Acked-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-10-05 07:58:37 -05:00
Anthony Liguori
7267c0947d Use glib memory allocation and free functions
qemu_malloc/qemu_free no longer exist after this commit.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-08-20 23:01:08 -05:00
Venkateswararao Jujjuri (JV)
faa44e3d3e [virtio-9p] Make rpath thread safe
Current rpath inline function is heavily used in all system calls.
This function has a static buffer making it a non-thread safe function.
This patch introduces new thread-safe routine and makes use of it.

Signed-off-by: Venkateswararao Jujjuri "<jvrao@linux.vnet.ibm.com>
2011-06-01 10:25:17 -07:00
Stefan Weil
873c321393 virtio-9p: Use relative includes for files in hw
Commit 353ac78d49 moved the files
without fixing the include paths. It used a modified CFLAGS
to add hw to the include search path, but this breaks builds
where the user wants to set special CFLAGS. Long include paths
also increase compilation time.

Therefore this patch removes the special CFLAGS for virtio
and fixes the include statements by using relative include paths.

v2: Remove special CFLAGS.
v3: Update needed for latest QEMU.

Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: Venkateswararao Jujjuri (JV) <jvrao@linux.vnet.ibm.com>
2011-06-01 10:25:03 -07:00
Aneesh Kumar K.V
353ac78d49 virtio-9p: move 9p files around
Now that we start adding more files related to 9pfs
it make sense to move them to a separate directory

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
2011-04-27 08:24:37 -07:00