• David S. Miller's avatar
    [IPV4]: Remove IP_TOS setting privilege checks. · e4f8b5d4
    David S. Miller authored
    Various RFCs have all sorts of things to say about the CS field of the
    DSCP value.  In particular they try to make the distinction between
    values that should be used by "user applications" and things like
    routing daemons.
    
    This seems to have influenced the CAP_NET_ADMIN check which exists for
    IP_TOS socket option settings, but in fact it has an off-by-one error
    so it wasn't allowing CS5 which is meant for "user applications" as
    well.
    
    Further adding to the inconsistency and brokenness here, IPV6 does not
    validate the DSCP values specified for the IPV6_TCLASS socket option.
    
    The real actual uses of these TOS values are system specific in the
    final analysis, and these RFC recommendations are just that, "a
    recommendation".  In fact the standards very purposefully use
    "SHOULD" and "SHOULD NOT" when describing how these values can be
    used.
    
    In the final analysis the only clean way to provide consistency here
    is to remove the CAP_NET_ADMIN check.  The alternatives just don't
    work out:
    
    1) If we add the CAP_NET_ADMIN check to ipv6, this can break existing
       setups.
    
    2) If we just fix the off-by-one error in the class comparison in
       IPV4, certain DSCP values can be used in IPV6 but not IPV4 by
       default.  So people will just ask for a sysctl asking to
       override that.
    
    I checked several other freely available kernel trees and they
    do not make any privilege checks in this area like we do.  For
    the BSD stacks, this goes back all the way to Stevens Volume 2
    and beyond.
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    e4f8b5d4
ip_sockglue.c 26.9 KB