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: <52B15F64.4070303@cn.fujitsu.com>
Date:	Wed, 18 Dec 2013 16:40:04 +0800
From:	Gao feng <gaofeng@...fujitsu.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
CC:	RongQing Li <roy.qing.li@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH] ipv6: clear RTF_EXPIRES when call ip6_rt_copy

On 12/18/2013 02:20 PM, Hannes Frederic Sowa wrote:
> On Wed, Dec 18, 2013 at 10:21:12AM +0800, RongQing Li wrote:
>> On Wed, Dec 18, 2013 at 10:09 AM, Gao feng <gaofeng@...fujitsu.com> wrote:
>>> On 12/18/2013 09:58 AM, RongQing Li wrote:
>>>> On Wed, Dec 18, 2013 at 8:48 AM, Gao feng <gaofeng@...fujitsu.com> wrote:
>>>>> On 12/17/2013 09:48 PM, Hannes Frederic Sowa wrote:
>>>>>> On Tue, Dec 17, 2013 at 03:46:24PM +0800, Gao feng wrote:
>>>>>>> The from of new cloned rt should not be set if it's impossible for the ort
>>>>>>> to be expired.
>>>>>>
>>>>>> Actually, why do you think so? What could go wrong?
>>>>>>
>>>>>
>>>>> I just don't want rt6_check_expired to check some impossible expired routes.
>>>>>
>>>>
>>>> What is wrong if we set from for new cloned rt by checking if ort has
>>>> RTF_EXPIRES flag?
>>>
>>>
>>> The RTF_EXPIRES flag may be changed by router advertisment package,
>>> the ort may become expired after you hadn't set from for new cloned rt.
>>>
>>> we should set from even this kind of ort doesn't have RTF_EXPIRES flag.
>>
>>
>> Thanks;
>>
>> Do we want to set from only from RA route?  if so,  we should check
>> ort with RTF_ADDRCONF|RTF_DEFAULT, or RTF_ADDRCONF | RTF_ROUTEINFO,
> 
> Nope, as I said, also prefix routes which did get installed by hand locally
> can have an expiration. I don't see any flag combination which ensure a
> potential from does never expire. IMHO we should always from.
> 
> Also, in case we overwrite a route and the route is already in there, we reset
> the expiry values: search for rt6_set_expires in fib6_add_rt2node.

Seem like user can add expired route by manually. rtmsg_to_fib6_config set the
cfg->fc_expires. I'm ok if you want to set from always now.

Thanks
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ