Responding to multiple issues raised above.
- Let us track this bug for the security/symlink issue and open a different
defect for the mount issue.
- I tried to reproduce this defect with the QEMU mainline. I don't see the
problem. More description on
the environment (Host OS/Guest OS/ QEMU command line etc) and how to
reproduce the problem will
be helpful.
[r...@localhost mmnt]# cat file1
omg it is important
[r...@localhost mmnt]# ln -sf file1 sym1
[r...@localhost mmnt]# ls -l
total 16
-rw-r--r-- 1 root root 20 2010-09-24 01:24 file1
lrwxrwxrwx 1 root root 6 2010-09-24 01:24 sym1 -> file1
[r...@localhost mmnt]# logout
- Moshroom:
- There are multiple security models here, if you use 'passthrough' same type
of files are created on the
host/guest. But if you use 'mapped' security model this is how we do it.
This security model is for cloud use case scenarios. Please read more in
this post
http://www.mail-archive.com/qemu-devel@nongnu.org/msg31452.html
- No need to use lsetattr/lgetattr here because we always create regular
files in this model.
--
VirtFS mapped symlinks resolved wrong
https://bugs.launchpad.net/bugs/646427
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: New
Bug description:
I tried to map a folder with qemu-kvm qemu-kvm-0.13.0-rc1-3-gc9c2179 (this is
v0.13.0-rc1-16667-gc9c2179). I mounted it first in passthrough mode and saw all
symlinks as expected. Then I used mapped and noticed that the target of a
symlink changed to the actual data inside the linked folder as target instead
of the target filename.
So for example if you have a file abc with the content "omg, this is important
stuff" and a symlink lnkme -> abc then it wiill look inside the kvm with
mounted 9p virtio (mapped) like that:
lnkme -> omg, this is important stuff
Another problem I noticed was that I cannot mount it (mapped or passthrough)
using /etc/rc.local or /etc/fstab, but after login as root using
mount /mnt
or
mount -t 9p -o trans=virtio host_share /mnt
(the same stuff i tried inside /etc/rc.local)
The only output on a failed mount in rc.local/fstab I get is
[ 15.035920] device: '9p-1': device_add
[ 15.038180] 9p: no channels available
[ 15.038937] device: '9p-1': device_unregister
[ 15.049123] device: '9p-1': device_create_release
