conclusiveeng / lib9p Goto Github PK

The arrays kev, event, and sockets, are allocated with a fixed size of 2. These arrays are populated with values derived from the result list returned from getaddrinfo. It is possible for getaddrinfo to return more than 2 addrinfo values in its return list. In the event that it does and that sockets are successfully created from each one, the sockets array would be overrun. In the following code that sets up event handlers for these sockets, the kev and event arrays would be overrun as well.

There are 2 ways to fix the problem. Either limit the for loop that runs the addrinfo list to 2, or malloc the kev, event, and sockets arrays based on the number of entries in the return list. In the case of limiting the for loop, I would make a define for the number of entries in these arrays and use the same defined value in the for loop. Something like:

#define MAXSOCK 2

...

struct kevent kev[MAXSOCK];
struct kevent event[MAXSOCK];
int sockets[MAXSOCK];

...

for (res = res0; res && nsockets < MAXSOCK; res = res->ai_next) {

I can submit a pull request for either solution.

Hi @jceel and lib9p-dev, thanks for great library :)
I use lib9p for docker-machine-driver-xhyve support 9p folder share(I think you already know, thanks issue comment!).
Also, I use you wrote the xhyve side code. Thanks again.
https://github.com/zchee/docker-machine-driver-xhyve/blob/master/vendor/github.com/zchee/libhyperkit/pci_virtio_9p.c

BTW, If I'm not wrong, I found a guest user permission(?) bug.
That can create any file, but can't remove this(or any) file, like using rm.

That occur on the latest commit of time of the found it. (not tested yet current latest)
But, not occur at 7be3e0b. (https://github.com/zchee/docker-machine-driver-xhyve/tree/master/vendor)

Sorry, I do not yet detailed debug for it. will do.
Just for reference, Here is simply reproduced way.
Note that it is only tested on the boot2docker OS built on top of docker-machine-driver-xhyve. It might be other causes.

config

• kexec:
  • -s 5,virtio-9p,host=/Users
  • https://github.com/zchee/docker-machine-driver-xhyve/blob/master/xhyve/xhyve.go#L430
• guest's mount command:
  • sudo mount -t 9p -o version=9p2000 -o trans=virtio -o uname=johndue -o dfltuid=1000 -o dfltgid=50 -o access=any host /Users
  • https://github.com/zchee/docker-machine-driver-xhyve/blob/master/xhyve/xhyve.go#L719

command on guest

dd if=/dev/zero of=/Users/johndoe/test bs=8k count=200k; rm -f /Users/johndoe/test

When create the zero filled file use dd, successful. but rm -f will fail with permission problem. This file still exists on the host.
I used config are same as you suggest variables, and xhyve side implement code is same as you folk xhyve.

Is it implements or require config has been changed? or a bug?

Off topic and question.
lib9p seems to already support the 9P2000.u/.L protocol.
I don't yet fully understand that protocol advantages, but 9P2000 is legacy, and it might be will provide a more performance (right?)

However, If use 9P2000.u/.L, does not work dfltuid and dfltgid config on lib9p. So AFAIK, can folder share, but can't create, edit files if different to uid|gid host and guest.
Is it by design of the 9p protocol? or implementation of lib9p?

I'd appreciate if you advise to me. and sorry for long comment and poor English :(
Thanks.

It seems lib9p and qemu disagree about protocol versions:

https://github.com/conclusiveeng/lib9p/blob/master/lib9p.h#L99-L104

enum l9p_version {
	L9P_INVALID_VERSION = 0,
	L9P_2000 = 1,
	L9P_2000U = 2,
	L9P_2000L = 3
};

vs

https://github.com/qemu/qemu/blob/master/hw/9pfs/9p.h#L98-L101

typedef enum P9ProtoVersion {
    V9FS_PROTO_2000U = 0x01,
    V9FS_PROTO_2000L = 0x02,
} P9ProtoVersion;

I ran into this when testing lib9p and bhyve with the virtfs from Juniper:

https://github.com/Juniper/virtfs/compare/jnpr/virtfs

Which is right, lib9p or qemu?

The test expects that if there are two fids referencing the same directory and that directory is renamed, then both fids can still be used to access the directory. Qemu's 9P server implements this by adjusting the paths for all affected fids after the rename.

This would allow calling getattr on unlinked files which is a fairly common pattern. For instance, FreeBSD's pkg uses this during 'pkg update'.

Looking at the code, I assume the answer is "no", but -- is there a way to have the backend expose a case-insensitive filesystem on the host as a case-sensitive filesystem to the guest? My use-case would be to expose a host's HFS+ filesystem (on osx) as a case-sensitive filesystem to linux guests instead of ~20GB files mounted as block devices.