lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070204.165235.26305735.davem@davemloft.net>
Date:	Sun, 04 Feb 2007 16:52:35 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	dkabs@...otix.com
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Problem with unix sockets: SOCK_DGRAM ignores MSG_TRUNC

From: Daniel Kabs <dkabs@...otix.com>
Date: Mon, 29 Jan 2007 12:59:49 +0100

> I use unix domain datagram sockets for IPC, e.g. I receive messages by 
> calling recv().
> 
> "man 2 recv" tells me about the flags argument to a recv() call, namely:
> 
>  MSG_TRUNC
>       Return  the  real  length of the packet, even when it was longer
>       than the passed buffer. Only valid for packet sockets.
> 
> Thus I used recv() with flags MSG_TRUNC|MSG_PEEK in order to detect 
> message truncation due to insufficient buffer size.

What part of "Only valid for packet sockets" from the manual page
escapes you?  :-))

It's a feature which only was meant to be valid for AF_PACKET sockets.

What UDP is doing is different, it's returning the full packet length
when the packet is larger then the given buffer size, but it does this
irregardless of whether you set MSG_TRUNC in the recvmsg() passed-in
flags.  UDP itself sets the MSG_TRUNC flag when it detects this
situation.

I checked the history and our AF_UNIX sockets have always behaved like
this.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ