This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Thu, Oct 06, 2016 at 01:19:00PM +0200, Florian Weimer wrote: > On 09/30/2016 01:10 PM, Stefan Hajnoczi wrote: > > On Thu, Sep 29, 2016 at 03:25:55PM +0200, Florian Weimer wrote: > > > * Stefan Hajnoczi: > > > > > > > Many existing programs use getnameinfo(3) and getaddrinfo(3). > > > > Porting programs to support AF_VSOCK is easy if the library > > > > functions can handle this address family. Without support in glibc > > > > each program needs to duplicate address parsing code and it becomes > > > > harder to port programs. > > > > > > What has changed since the previous discussion? > > > > > > <https://sourceware.org/ml/libc-help/2015-08/msg00004.html> > > > > > > How do you expect that applications will know that they have to pass > > > AF_VSOCK to getaddrinfo instead of AF_UNSPEC? > > > > For example ncat(1) has --unixsock and --udp command-line options. A > > --vsock option can be added. At that point the program knows to use > > AF_VSOCK and the same getaddrinfo(3) code path can be used by TCP, UDP, > > UNIX, and vsock. > > ncat doesn't use getaddrinfo AFAICS, so this isn't going to help it. The > larger nmap codebase has a call to getaddrinfo, but the code leading to it > assumes 16-bit port numbers, so it won't be able to use getaddrinfo either. > > Do you have a better example? I just sent nfs-utils patches for mount.nfs(8): https://marc.info/?l=linux-nfs&m=147583470431780&w=2 The nfs-utils code passes around a struct addrinfo pointer obtained by getaddrinfo(3) from nfs_try_mount(). If getaddrinfo(3) supports .ai_family = AF_VSOCK then it's easy to reuse the existing code without adding special cases for AF_VSOCK. > Is there a test guest system which has NFS over AF_VSOCK running? Sure, I can set something up for you. > It looks > to me that AF_VSOCK is fundamentally insecure, and I'm not sure if it can be > fixed. In what way?
Attachment:
signature.asc
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |