netdev - RE: NETLINK sockets dont honor SO

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]

Date:	Wed, 18 Nov 2009 10:41:06 -0800
From:	Jeff Haran <jharan@...cade.COM>
To:	David Miller <davem@...emloft.net>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: NETLINK sockets dont honor SO_RCVLOWAT?

> -----Original Message-----
> From: David Miller [mailto:davem@...emloft.net] 
> Sent: Wednesday, November 18, 2009 10:25 AM
> To: Jeff Haran
> Cc: netdev@...r.kernel.org
> Subject: Re: NETLINK sockets dont honor SO_RCVLOWAT?
> 
> From: Jeff Haran <jharan@...cade.COM>
> Date: Wed, 18 Nov 2009 10:22:54 -0800
> 
> > So is this a bug or a feature?
> 
> It definitely seems intentional.
> 
> > When I call setsockopt() to set this option on a NETLINK socket,
> > setsockopt() appears to return 0 to indicate success. If it's not
> > going to be supported, shouldn't setsockopt() return -1 with
> > ENOPROTOOPT in errno in this case?
> 
> There are a lot of socket option values that can be set but which
> are not used by the protocol in question.

All that means is that there are a lot of bugs.

> 
> I don't think any changes need to be made.

>From the setsockopt man page:

SETSOCKOPT(P)                                                   SETSOCKOPT(P)

NAME
       setsockopt - set the socket options

SYNOPSIS
       #include <sys/socket.h>

       int setsockopt(int socket, int level, int option_name,
              const void *option_value, socklen_t option_len);
...

ERRORS
       The setsockopt() function shall fail if:
...

       ENOPROTOOPT

              The option is not supported by the protocol.


The operative term is "shall". The RFCs define "shall" to be required behavior. I realize the RFCs do not dictate how Linux works, but even the common English language usage of the word "shall" conveys this meaning.

Thanks,

Jeff Haran
Brocade Communications
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html