--- Begin Message ---
- Subject: Re: [patch 9/9] Implement better error reporting
- From: "Richard W.M. Jones" <rjones@xxxxxxxxxx>
- Date: Thu, 22 Feb 2007 14:03:25 +0000
- Cc: "Daniel P. Berrange" <berrange@xxxxxxxxxx>, libvir-list@xxxxxxxxxx
- In-reply-to: <1171908807.3963.44.camel@blaa>
- References: <20070216144026.569614622@xxxxxxxxxx> <20070216144155.830735752@xxxxxxxxxx> <20070216192804.GH20122@xxxxxxxxxx> <1171908807.3963.44.camel@blaa>
- User-agent: Thunderbird 1.5.0.9 (X11/20070212)
Mark McLoughlin wrote:Doesn't accept() fail if the client fails to send the final ACK? Do we want the daemon to die in that case? Think of an unprivileged user connecting to the system daemon's readonly socket ... you really want to be paranoid about the daemon exiting as it creates the opportunity for unprivileged users to take down guests and networks. i.e. I'm not sure whether it would be actually possible to exploit it in this way, but I'd tend to be pretty paranoid about any exit point from the daemon.On a similar topic, does anyone know if gnutls_handshake can be DoS'd by a client running arbitrarily slowly? At the moment if someone (even an untrusted host) makes a TCP connection to libvirtd but then doesn't do anything very much then no one else can connect for the duration. I can partly get around this by checking the IP address of the peer much earlier on (after accept() but before any GnuTLS start-up), but that only solves the problem if we're doing very crude IP-level checks, not user-level certificates from a single IP.Rich.Attachment: smime.p7s
Description: S/MIME Cryptographic Signature
--- End Message ---
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature