Merge lp:~christian-roeller/hipl/whitelisting into lp:hipl

Proposed by Christian Röller
Status: Needs review
Proposed branch: lp:~christian-roeller/hipl/whitelisting
Merge into: lp:hipl
Diff against target: 712 lines (+322/-89)
8 files modified
Makefile.am (+14/-7)
hipd/input.c (+1/-1)
hipd/netdev.c (+137/-80)
hipd/netdev.h (+3/-0)
test/check_hipd.c (+41/-0)
test/hipd/netdev.c (+92/-0)
test/hipd/test_suites.h (+33/-0)
test/lib/core/hostid.c (+1/-1)
To merge this branch: bzr merge lp:~christian-roeller/hipl/whitelisting
Reviewer Review Type Date Requested Status
Stefan Götz (community) Needs Fixing
Diego Biurrun Needs Fixing
Christof Mroz Needs Fixing
René Hummen Pending
Review via email: mp+75343@code.launchpad.net

This proposal supersedes a proposal from 2011-09-13.

Description of the change

Change in the whitelisting of hipl:

The problem with the current whitelisting fuction is, that it only considers the interface-indexes. So when you for instance want to whitelist your eth0 interface, but there are also alias-interfaces for this interface on your machine, then a change for this alias-interfaces would also trigger an update, because these interfaces have the same interface-index for the kernel.

To have a more concrete possibility to whitelist interfaces, I extend the whitelist-structure with the interface-label. So that when you now whitelist your interface eth0, only changes on this interface would trigger an update and not for the alias-interfaces.

I did this by just checking for every incoming NEWADDR netlinkevent, if the corresponding label for this address is whitelisted or not.

So please have a look and just tell if you are fine with this...

To post a comment you must log in.
Revision history for this message
Stefan Götz (stefan.goetz-deactivatedaccount) wrote : Posted in a previous version of this proposal
Download full text (7.4 KiB)

Hi Christian!

Thanks for this helpful contribution! My comments below:

> > === modified file 'hipd/netdev.c'
> > --- hipd/netdev.c 2011-05-31 18:21:28 +0000
> > +++ hipd/netdev.c 2011-07-14 15:34:41 +0000
> > -static void hip_netdev_white_list_add_index(int if_index)
> > +static void hip_netdev_white_list_add_index_and_name(int if_index, const char *const device_name)

[L] cleanup: please add a 'const' modifier to the 'if_index' argument
[L] cleanup: I guess that 'if_index' cannot be less than 0. If so, it would be
nice to change its type to unsigned to communicate this fact to the caller.

> > {
> > if (hip_netdev_white_list_count < HIP_NETDEV_MAX_WHITE_LIST) {
> > - hip_netdev_white_list[hip_netdev_white_list_count++] = if_index;
> > + hip_netdev_white_list[hip_netdev_white_list_count].if_index = if_index;
> > + strncpy(hip_netdev_white_list[hip_netdev_white_list_count].if_label, device_name, IF_NAMESIZE);
[L] maintainability: it is more maintainable to use
'sizeof(hip_netdev_white_list[0].if_label)' than 'IF_NAMESIZE' because then the
size of the 'if_label' field can be changed in the struct declaration without
having to touch other code.

> > @@ -120,16 +127,18 @@
> > }
> >
> > /**
> > - * Test if the given network interface index is white listed.
> > + * Test if the given network interface index plus label is white listed.
> > *
> > * @param if_index the index of the network interface to be tested
> > + * @param device_name the label of the network interface to be tested
> > * @return 1 if the index is whitelisted or zero otherwise
> > */
> > -static int hip_netdev_is_in_white_list(int if_index)
> > +static int hip_netdev_is_in_white_list(int if_index, char *device_name)

[M] policy: please apply full const correctness to the function arguments.
[L] cleanup: it would be nice to change the type of 'if_index' to unsigned as it
can never be < 0 (I guess)

> > {
> > - int i = 0;
> > + int i;
> > for (i = 0; i < hip_netdev_white_list_count; i++) {

[L] style: you could even place the declaration of 'i' in the for() header.

> > - if (hip_netdev_white_list[i] == if_index) {
> > + if (hip_netdev_white_list[i].if_index == if_index &&
> > + !strncmp(hip_netdev_white_list[i].if_label, device_name, IF_NAMESIZE)) {

[L] maintainability: 'sizeof()' instead of 'IF_NAMESIZE', see above

> > @@ -637,7 +645,7 @@
> > HIP_IFEL(!(if_index = if_nametoindex(g_iface->ifa_name)),
> > -1, "if_nametoindex failed\n");
> > /* Check if our interface is in the whitelist */
> > - if ((hip_netdev_white_list_count > 0) && (!hip_netdev_is_in_white_list(if_index))) {
> > + if ((hip_netdev_white_list_count > 0) && (!hip_netdev_is_in_white_list(if_index, g_iface->ifa_name))) {

[L] style: just a general comment: it would make more sense to move the '> 0'
check into the 'hip_netdev_is_in_white_list()' function so the caller does not
need to have internal knowledge about the list implementation. Furthermore it's
a really silly performance optimization.

> > @@ -1125,6 +1133,55 @@
> > }
> >
> > /**
> > + * find interface label for a given ip4 or ip6 addr
...

Read more...

review: Needs Fixing
Revision history for this message
Miika Komu (miika-iki) wrote : Posted in a previous version of this proposal

Quick test report: seems to work without any troubles.

Revision history for this message
Christian Röller (christian-roeller) wrote : Posted in a previous version of this proposal
Download full text (9.2 KiB)

Once my exam is over I have finally found the time to work on your improvement suggestions...

> Hi Christian!
>
> Thanks for this helpful contribution! My comments below:
>
> > > === modified file 'hipd/netdev.c'
> > > --- hipd/netdev.c 2011-05-31 18:21:28 +0000
> > > +++ hipd/netdev.c 2011-07-14 15:34:41 +0000
> > > -static void hip_netdev_white_list_add_index(int if_index)
> > > +static void hip_netdev_white_list_add_index_and_name(int if_index, const
> char *const device_name)
>
> [L] cleanup: please add a 'const' modifier to the 'if_index' argument
> [L] cleanup: I guess that 'if_index' cannot be less than 0. If so, it would be
> nice to change its type to unsigned to communicate this fact to the caller.

Both done, you are right no reason here for dont make it unsigned and const...

>
> > > {
> > > if (hip_netdev_white_list_count < HIP_NETDEV_MAX_WHITE_LIST) {
> > > - hip_netdev_white_list[hip_netdev_white_list_count++] = if_index;
> > > + hip_netdev_white_list[hip_netdev_white_list_count].if_index =
> if_index;
> > > +
> strncpy(hip_netdev_white_list[hip_netdev_white_list_count].if_label,
> device_name, IF_NAMESIZE);
> [L] maintainability: it is more maintainable to use
> 'sizeof(hip_netdev_white_list[0].if_label)' than 'IF_NAMESIZE' because then
> the
> size of the 'if_label' field can be changed in the struct declaration without
> having to touch other code.

Good point I didnt take this into account, its changed now

>
> > > @@ -120,16 +127,18 @@
> > > }
> > >
> > > /**
> > > - * Test if the given network interface index is white listed.
> > > + * Test if the given network interface index plus label is white listed.
> > > *
> > > * @param if_index the index of the network interface to be tested
> > > + * @param device_name the label of the network interface to be tested
> > > * @return 1 if the index is whitelisted or zero otherwise
> > > */
> > > -static int hip_netdev_is_in_white_list(int if_index)
> > > +static int hip_netdev_is_in_white_list(int if_index, char *device_name)
>
> [M] policy: please apply full const correctness to the function arguments.
> [L] cleanup: it would be nice to change the type of 'if_index' to unsigned as
> it
> can never be < 0 (I guess)

Same as above, so done...

>
> > > {
> > > - int i = 0;
> > > + int i;
> > > for (i = 0; i < hip_netdev_white_list_count; i++) {
>
> [L] style: you could even place the declaration of 'i' in the for() header.

Yes I can, so I did... ;-) The actual writer did it like this, so I just adopt it...

>
> > > - if (hip_netdev_white_list[i] == if_index) {
> > > + if (hip_netdev_white_list[i].if_index == if_index &&
> > > + !strncmp(hip_netdev_white_list[i].if_label, device_name,
> IF_NAMESIZE)) {
>
> [L] maintainability: 'sizeof()' instead of 'IF_NAMESIZE', see above

Done...but I use sizeof()-1 to do not override the null-termination

>
> > > @@ -637,7 +645,7 @@
> > > HIP_IFEL(!(if_index = if_nametoindex(g_iface->ifa_name)),
> > > -1, "if_nametoindex failed\n");
> > > /* Check if our interface is in the whitelist */
> > > - if ((hip_netdev_white_list_count ...

Read more...

Revision history for this message
Stefan Götz (stefan.goetz-deactivatedaccount) wrote : Posted in a previous version of this proposal
Download full text (4.4 KiB)

Hi Christian!

Thanks for your detailed reply! I was on holidays so that's why my answer is
quite late:

>>>> - if (hip_netdev_white_list[i] == if_index) {
>>>> + if (hip_netdev_white_list[i].if_index == if_index &&
>>>> + !strncmp(hip_netdev_white_list[i].if_label, device_name,
>> IF_NAMESIZE)) {
>>
>> [L] maintainability: 'sizeof()' instead of 'IF_NAMESIZE', see above
>
> Done...but I use sizeof()-1 to do not override the null-termination

Hm - in the case of the read-only 'strncmp()' function, I'm pretty sure that you
want to check both strings to their full extent, including the null-terminating
character. Otherwise, you can get false positives with unterminated strings (I
know, that's a pathological case, but still, passing 'sizeof() - 1' to
'strncmp()' seems logically incorrect to me).

>>>> +int hip_find_label_for_address(struct sockaddr *addr, char *label)
>>
>> [M] policy: please ensure full const correctness
>
> I write to label and cast addr, so I cannot declare const, can I?

You can use 'const struct sockaddr *const addr' and cast it to 'const struct
sockaddr_in const* s4_in'. Similarly, you can use 'char *const label' as you do
not intend to or do change the pointer value.

>>>> + res = getifaddrs(&myaddrs);
>>>> + for (ifa = myaddrs; ifa != NULL; ifa = ifa->ifa_next) {
>>>> + if (ifa->ifa_addr == NULL) continue;
>>>> + if (ifa->ifa_addr->sa_family != AF_INET &&
>> ifa->ifa_addr->sa_family != AF_INET6) continue;
>>
>> [M] policy: HIPL always uses "long" if statements including braces and
>> newlines.
>> Please adhere to that style. Do you use the pre-commit hook for checking your
>> code style? I'm asking because I'm surprised that the checker does not catch
>> this.
>
> For me the statement doesnt include braces or a new line. Maybe I have changed it and forgot to commit it...maybe you can check it again...

Exactly my point: it *should* include braces and newlines but currently it does
not :-) It should read

if (ifa->ifa_addr == NULL) {
 continue;
}

etc.

>> [L] maintainability: similar to the above cases, 'sizeof(s4_in)' would be more
>> easily maintainable and more obvious to read than 'sizeof(struct
>> sockaddr_in)'.
>> The same applies to the code below.
>>
>>>> + strncpy(label, ifa->ifa_name, IF_NAMESIZE);
>>
>> [L] 'sizeof()'
>
> Both done, like described above...

Just like 'strncmp()', 'strncpy()' should use the full character array - the
code should also check that the string to copy is not longer than the given
character array - 1 or otherwise return an error from the function. Only this
combination will ensure that the string is either copied correctly or an error
is detected under all circumstances.

>>>> + freeifaddrs(myaddrs);
>>>> + return 1;
>>>> + }
>>>> + }
>>>> + if (ifa->ifa_addr->sa_family == AF_INET6) {
>>>> + s6 = (struct sockaddr_in6 *)(ifa->ifa_addr);
>>>> + if (!memcmp(s6_in, s6, sizeof(struct sockaddr_in6))) {
>>>> + strncpy(label, ifa->ifa_name, IF_NAMESIZE);
>>>> + freeifaddrs(myaddrs);
>>>> + return 1;
>>
>> [L] styl...

Read more...

Revision history for this message
Christian Röller (christian-roeller) wrote : Posted in a previous version of this proposal
Download full text (5.1 KiB)

> Hi Christian!
>
> Thanks for your detailed reply! I was on holidays so that's why my answer is
> quite late:

No problem my first reply has also taken a while due to my exam preparations ;-)

>
> >>>> - if (hip_netdev_white_list[i] == if_index) {
> >>>> + if (hip_netdev_white_list[i].if_index == if_index &&
> >>>> + !strncmp(hip_netdev_white_list[i].if_label, device_name,
> >> IF_NAMESIZE)) {
> >>
> >> [L] maintainability: 'sizeof()' instead of 'IF_NAMESIZE', see above
> >
> > Done...but I use sizeof()-1 to do not override the null-termination
>
> Hm - in the case of the read-only 'strncmp()' function, I'm pretty sure that
> you
> want to check both strings to their full extent, including the null-
> terminating
> character. Otherwise, you can get false positives with unterminated strings (I
> know, that's a pathological case, but still, passing 'sizeof() - 1' to
> 'strncmp()' seems logically incorrect to me).

Yes of course...I never did it in the code. This was just a comment at the wrong position.

>
> >>>> +int hip_find_label_for_address(struct sockaddr *addr, char *label)
> >>
> >> [M] policy: please ensure full const correctness
> >
> > I write to label and cast addr, so I cannot declare const, can I?
>
> You can use 'const struct sockaddr *const addr' and cast it to 'const struct
> sockaddr_in const* s4_in'. Similarly, you can use 'char *const label' as you
> do
> not intend to or do change the pointer value.

Yes you are right, did it.

>
> >>>> + res = getifaddrs(&myaddrs);
> >>>> + for (ifa = myaddrs; ifa != NULL; ifa = ifa->ifa_next) {
> >>>> + if (ifa->ifa_addr == NULL) continue;
> >>>> + if (ifa->ifa_addr->sa_family != AF_INET &&
> >> ifa->ifa_addr->sa_family != AF_INET6) continue;
> >>
> >> [M] policy: HIPL always uses "long" if statements including braces and
> >> newlines.
> >> Please adhere to that style. Do you use the pre-commit hook for checking
> your
> >> code style? I'm asking because I'm surprised that the checker does not
> catch
> >> this.
> >
> > For me the statement doesnt include braces or a new line. Maybe I have
> changed it and forgot to commit it...maybe you can check it again...
>
> Exactly my point: it *should* include braces and newlines but currently it
> does
> not :-) It should read
>
> if (ifa->ifa_addr == NULL) {
> continue;
> }
>
> etc.

Ah OK now I got your point...sorry ;-) I changed it

>
> >> [L] maintainability: similar to the above cases, 'sizeof(s4_in)' would be
> more
> >> easily maintainable and more obvious to read than 'sizeof(struct
> >> sockaddr_in)'.
> >> The same applies to the code below.
> >>
> >>>> + strncpy(label, ifa->ifa_name, IF_NAMESIZE);
> >>
> >> [L] 'sizeof()'
> >
> > Both done, like described above...
>
> Just like 'strncmp()', 'strncpy()' should use the full character array - the
> code should also check that the string to copy is not longer than the given
> character array - 1 or otherwise return an error from the function. Only this
> combination will ensure that the string is either copied correctly or an error
> is detected under all circumstances.

OK, I changed it in the following way:
I chec...

Read more...

Revision history for this message
Stefan Götz (stefan.goetz-deactivatedaccount) : Posted in a previous version of this proposal
review: Approve
Revision history for this message
Diego Biurrun (diego-biurrun) wrote : Posted in a previous version of this proposal

 review needs-fixing

On Thu, Jul 14, 2011 at 03:34:45PM +0000, Christian Röller wrote:
> Christian Röller has proposed merging lp:~christian-roeller/hipl/whitelisting into lp:hipl.

Formatting is messed-up. Didn't you install the uncrustify pre-commit
hook as described in doc/HACKING? Why?

Diego

review: Needs Fixing
Revision history for this message
Christian Röller (christian-roeller) wrote : Posted in a previous version of this proposal

> review needs-fixing
>
> On Thu, Jul 14, 2011 at 03:34:45PM +0000, Christian Röller wrote:
> > Christian Röller has proposed merging lp:~christian-
> roeller/hipl/whitelisting into lp:hipl.
>
> Formatting is messed-up. Didn't you install the uncrustify pre-commit
> hook as described in doc/HACKING? Why?
>
> Diego

Sorry for that, I checked now my modifications with the stylechecker and correct everything it complained about.

Revision history for this message
Diego Biurrun (diego-biurrun) wrote : Posted in a previous version of this proposal

On Mon, Aug 01, 2011 at 09:19:26AM +0000, Christian Röller wrote:
> > On Thu, Jul 14, 2011 at 03:34:45PM +0000, Christian Röller wrote:
> > > Christian Röller has proposed merging lp:~christian-
> > roeller/hipl/whitelisting into lp:hipl.
> >
> > Formatting is messed-up. Didn't you install the uncrustify pre-commit
> > hook as described in doc/HACKING? Why?
>
> Sorry for that, I checked now my modifications with the stylechecker
> and correct everything it complained about.

I'm not trying to pass blame around. I want to know why some of our
processes are not working as intended, so that we can fix them.

Why were you not running uncrustify? Did you just forget to install
the hook (no big deal, we all make mistakes and we have review for a
reason) or did you not know about it? Where would we have to advertise
it so that the next newcomer is informed of its existence?

Diego

Revision history for this message
Christian Röller (christian-roeller) wrote : Posted in a previous version of this proposal

> On Mon, Aug 01, 2011 at 09:19:26AM +0000, Christian Röller wrote:
> > > On Thu, Jul 14, 2011 at 03:34:45PM +0000, Christian Röller wrote:
> > > > Christian Röller has proposed merging lp:~christian-
> > > roeller/hipl/whitelisting into lp:hipl.
> > >
> > > Formatting is messed-up. Didn't you install the uncrustify pre-commit
> > > hook as described in doc/HACKING? Why?
> >
> > Sorry for that, I checked now my modifications with the stylechecker
> > and correct everything it complained about.
>
> I'm not trying to pass blame around. I want to know why some of our
> processes are not working as intended, so that we can fix them.
>
> Why were you not running uncrustify? Did you just forget to install
> the hook (no big deal, we all make mistakes and we have review for a
> reason) or did you not know about it? Where would we have to advertise
> it so that the next newcomer is informed of its existence?
>
> Diego

I have heard that there is a hook for this, but as this is my first share,
I just forgot to install it.
So in this case it was just my fault...
But for the next newcomers, it would be nice to advertise the HACKING doc a
little bit more, because it is very helpful and I don't know about it. I just
heard about the stylechecker through the grapevine.

So sorry again and thanks for the infos...
Christian

Revision history for this message
Diego Biurrun (diego-biurrun) wrote : Posted in a previous version of this proposal

On Mon, Aug 01, 2011 at 09:59:28AM +0000, Christian Röller wrote:
> > On Mon, Aug 01, 2011 at 09:19:26AM +0000, Christian Röller wrote:
> > > > On Thu, Jul 14, 2011 at 03:34:45PM +0000, Christian Röller wrote:
> > > > > Christian Röller has proposed merging lp:~christian-
> > > > roeller/hipl/whitelisting into lp:hipl.
> > > >
> > > > Formatting is messed-up. Didn't you install the uncrustify pre-commit
> > > > hook as described in doc/HACKING? Why?
> > >
> > > Sorry for that, I checked now my modifications with the stylechecker
> > > and correct everything it complained about.
> >
> > I'm not trying to pass blame around. I want to know why some of our
> > processes are not working as intended, so that we can fix them.
> >
> > Why were you not running uncrustify? Did you just forget to install
> > the hook (no big deal, we all make mistakes and we have review for a
> > reason) or did you not know about it? Where would we have to advertise
> > it so that the next newcomer is informed of its existence?
>
> I have heard that there is a hook for this, but as this is my first share,
> I just forgot to install it.
> So in this case it was just my fault...

I repeat: I'm not trying to pass blame around. Stop apologizing please.

> But for the next newcomers, it would be nice to advertise the HACKING doc a
> little bit more, because it is very helpful and I don't know about it. I just
> heard about the stylechecker through the grapevine.

I've updated INSTALL and the PISA wiki slightly. There's still room for
improvement though.

Diego

Revision history for this message
Christian Röller (christian-roeller) wrote : Posted in a previous version of this proposal

Hi,

sorry for my long absence, it was again exam-time ;-)

So I correct everything, which were mentioned. Are there more improvement suggestions or any other reasons why it should not be merged in this version?
Otherwise I would do so.
I merged it locally and as there are only a few changes in two files, it works without any trouble.
The same applies for the compiling.

Regards,
Christian

Revision history for this message
René Hummen (rene-hummen) wrote : Posted in a previous version of this proposal

Diego, have your comments been tackled? If so, please approve the merge request.

Revision history for this message
Diego Biurrun (diego-biurrun) wrote : Posted in a previous version of this proposal

On Wed, Aug 10, 2011 at 02:07:38PM +0000, Christian Röller wrote:
>
> So I correct everything, which were mentioned. Are there more
> improvement suggestions or any other reasons why it should not be
> merged in this version?
> Otherwise I would do so.

The general idea is that you resubmit a fixed merge proposal.

Diego

Revision history for this message
Diego Biurrun (diego-biurrun) wrote : Posted in a previous version of this proposal

On Wed, Aug 10, 2011 at 02:39:35PM +0000, René Hummen wrote:
> Diego, have your comments been tackled? If so, please approve the merge request.

There was no updated merge request, so the answer is no.

Diego

Revision history for this message
Christian Röller (christian-roeller) wrote : Posted in a previous version of this proposal

> On Wed, Aug 10, 2011 at 02:39:35PM +0000, René Hummen wrote:
> > Diego, have your comments been tackled? If so, please approve the merge
> request.
>
> There was no updated merge request, so the answer is no.
>
> Diego

I correct the code style violations with revision 5987.
What do you mean with updated merge request? I answered on your needs-fixing comment and correct it.
I did the same for Stefan's needs-fixing request and he approved it.
What should I rather have done?

Christian

Revision history for this message
René Hummen (rene-hummen) wrote : Posted in a previous version of this proposal

On 10.08.2011, at 17:11, Christian Röller wrote:
>> On Wed, Aug 10, 2011 at 02:39:35PM +0000, René Hummen wrote:
>>> Diego, have your comments been tackled? If so, please approve the merge
>> request.
>>
>> There was no updated merge request, so the answer is no.
>>
>> Diego
>
> I correct the code style violations with revision 5987.
> What do you mean with updated merge request? I answered on your needs-fixing comment and correct it.
> I did the same for Stefan's needs-fixing request and he approved it.
> What should I rather have done?

In the top right corner of your merge proposal page on the Launchpad website, you can follow the link "Resubmit proposal". Don't check the option to "start afresh" in order to keep the discussion history intact and for others to follow the whole conversation.

Ciao,
René

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 20772
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/

Revision history for this message
Diego Biurrun (diego-biurrun) wrote : Posted in a previous version of this proposal

On Wed, Aug 10, 2011 at 03:11:23PM +0000, Christian Röller wrote:
> > On Wed, Aug 10, 2011 at 02:39:35PM +0000, René Hummen wrote:
> > > Diego, have your comments been tackled? If so, please approve the merge
> > request.
> >
> > There was no updated merge request, so the answer is no.
>
> I correct the code style violations with revision 5987.
> What do you mean with updated merge request? I answered on your
> needs-fixing comment and correct it.
> I did the same for Stefan's needs-fixing request and he approved it.
> What should I rather have done?

Maybe you did fix it in your branch, but how would we know? We never
had a chance to see and review it. What you should do now is send
another merge request from your updated branch.

Diego

Revision history for this message
Diego Biurrun (diego-biurrun) wrote : Posted in a previous version of this proposal

On Wed, Aug 10, 2011 at 03:28:27PM +0000, Christian Röller wrote:
> Christian Röller has proposed merging lp:~christian-roeller/hipl/whitelisting into lp:hipl.

Did you run

  make alltests
  tools/hipl_autobuild.sh

with this branch?

> --- hipd/netdev.c 2011-05-25 09:22:19 +0000
> +++ hipd/netdev.c 2011-08-10 15:28:20 +0000
> @@ -99,19 +99,26 @@
> -static void hip_netdev_white_list_add_index(int if_index)
> +static void hip_netdev_white_list_add_index_and_name(const unsigned int if_index, const char *const device_name)

Please keep lines below 80 characters where easily possible, like here.

More examples below...

> @@ -1122,6 +1131,68 @@
>
> /**
> + * This functions gives you the interface label for a given ip4 or ip6 addr.

IPv4, IPv6 address

> + * @param addr address for which you want to know the label
> + * @param label pointer where the function stores the label
> + * @return one on success, zero on error and write the label in param label

Is the label written in both cases?

> +int hip_find_label_for_address(const struct sockaddr *const addr, char *const label)
> +{
> +
> + if (addr->sa_family == AF_INET) {
> + s4_in = (const struct sockaddr_in *const) (addr);
> + }
> + if (addr->sa_family == AF_INET6) {
> + s6_in = (const struct sockaddr_in6 *const) (addr);
> + }

An else will save you a comparison here.

> + getifaddrs(&myaddrs);
> + for (ifa = myaddrs; ifa != NULL; ifa = ifa->ifa_next) {
> + if (ifa->ifa_addr == NULL) {
> + continue;
> + }
> + if (ifa->ifa_addr->sa_family != AF_INET && ifa->ifa_addr->sa_family != AF_INET6) {
> + continue;
> + }

These two could be merged.

> + if (ifa->ifa_addr->sa_family == AF_INET) {
> + s4 = (struct sockaddr_in *) (ifa->ifa_addr);

pointless ()

> + if (ifa->ifa_addr->sa_family == AF_INET6) {
> + s6 = (struct sockaddr_in6 *) (ifa->ifa_addr);

pointless ()

As above, if you use else here, you could save a comparison.

> + if (!memcmp(s4_in, s4, sizeof(s4))) {
> + if (strlen(ifa->ifa_name) <= sizeof(label) - 1) {
> + strncpy(label, ifa->ifa_name, sizeof(label) - 1);
> + res = 1;
> + } else {
> + res = 0;
> + }
> + break;

> + if (!memcmp(s6_in, s6, sizeof(s6))) {
> + if (strlen(ifa->ifa_name) <= sizeof(label) - 1) {
> + strncpy(label, ifa->ifa_name, sizeof(label) - 1);
> + res = 1;
> + } else {
> + res = 0;
> + }
> + break;

Isn't there a way to avoid this code duplication?

Diego

Revision history for this message
Diego Biurrun (diego-biurrun) : Posted in a previous version of this proposal
review: Needs Fixing
Revision history for this message
Stefan Götz (stefan.goetz-deactivatedaccount) wrote : Posted in a previous version of this proposal

Fixing Diego's comments sure won't hurt, but otherwise I'm okay with this.

review: Approve
Revision history for this message
Christian Röller (christian-roeller) wrote : Posted in a previous version of this proposal
Download full text (3.3 KiB)

> On Wed, Aug 10, 2011 at 03:28:27PM +0000, Christian Röller wrote:
> > Christian Röller has proposed merging lp:~christian-
> roeller/hipl/whitelisting into lp:hipl.
>
> Did you run
>
> make alltests
> tools/hipl_autobuild.sh

Yes I run make alltests. It seems to be OK, I get no errors and it results with "archives ready for distribution".
I am not really sure how to use the autobuild script. How and from which machine can I run this script manually to build my branch?
Can it come to problems, although make and make alltests run without ones?

>
> with this branch?
>
> > --- hipd/netdev.c 2011-05-25 09:22:19 +0000
> > +++ hipd/netdev.c 2011-08-10 15:28:20 +0000
> > @@ -99,19 +99,26 @@
> > -static void hip_netdev_white_list_add_index(int if_index)
> > +static void hip_netdev_white_list_add_index_and_name(const unsigned int
> if_index, const char *const device_name)
>
> Please keep lines below 80 characters where easily possible, like here.

Done...

>
> More examples below...
>
> > @@ -1122,6 +1131,68 @@
> >
> > /**
> > + * This functions gives you the interface label for a given ip4 or ip6
> addr.
>
> IPv4, IPv6 address

Done...

>
> > + * @param addr address for which you want to know the label
> > + * @param label pointer where the function stores the label
> > + * @return one on success, zero on error and write the label in param label
>
> Is the label written in both cases?

Done...only if the address exists in the system

>
> > +int hip_find_label_for_address(const struct sockaddr *const addr, char
> *const label)
> > +{
> > +
> > + if (addr->sa_family == AF_INET) {
> > + s4_in = (const struct sockaddr_in *const) (addr);
> > + }
> > + if (addr->sa_family == AF_INET6) {
> > + s6_in = (const struct sockaddr_in6 *const) (addr);
> > + }
>
> An else will save you a comparison here.
>
> > + getifaddrs(&myaddrs);
> > + for (ifa = myaddrs; ifa != NULL; ifa = ifa->ifa_next) {
> > + if (ifa->ifa_addr == NULL) {
> > + continue;
> > + }
> > + if (ifa->ifa_addr->sa_family != AF_INET && ifa->ifa_addr->sa_family
> != AF_INET6) {
> > + continue;
> > + }
>
> These two could be merged.
>
> > + if (ifa->ifa_addr->sa_family == AF_INET) {
> > + s4 = (struct sockaddr_in *) (ifa->ifa_addr);
>
> pointless ()
>
> > + if (ifa->ifa_addr->sa_family == AF_INET6) {
> > + s6 = (struct sockaddr_in6 *) (ifa->ifa_addr);
>
> pointless ()
>
> As above, if you use else here, you could save a comparison.
>
> > + if (!memcmp(s4_in, s4, sizeof(s4))) {
> > + if (strlen(ifa->ifa_name) <= sizeof(label) - 1) {
> > + strncpy(label, ifa->ifa_name, sizeof(label) - 1);
> > + res = 1;
> > + } else {
> > + res = 0;
> > + }
> > + break;
>
> > + if (!memcmp(s6_in, s6, sizeof(s6))) {
> > + if (strlen(ifa->ifa_name) <= sizeof(label) - 1) {
> > + strncpy(label, ifa->ifa_name, sizeof(label) - 1);
> > + res = 1;
> > + } else {
> > + ...

Read more...

Revision history for this message
Diego Biurrun (diego-biurrun) wrote : Posted in a previous version of this proposal

On Thu, Aug 11, 2011 at 11:47:26AM +0000, Christian Röller wrote:
> > On Wed, Aug 10, 2011 at 03:28:27PM +0000, Christian Röller wrote:
> > > Christian Röller has proposed merging lp:~christian-
> > roeller/hipl/whitelisting into lp:hipl.
> >
> > Did you run
> >
> > make alltests
> > tools/hipl_autobuild.sh
>
> Yes I run make alltests. It seems to be OK, I get no errors and it
> results with "archives ready for distribution". I am not really sure
> how to use the autobuild script. How and from which machine can I run
> this script manually to build my branch?

Did you try running or reading the script?

> Can it come to problems, although make and make alltests run without ones?

Yes.

Diego

Revision history for this message
Diego Biurrun (diego-biurrun) wrote : Posted in a previous version of this proposal

 review needs-fixing

On Thu, Aug 11, 2011 at 11:48:47AM +0000, Christian Röller wrote:
> Christian Röller has proposed merging lp:~christian-roeller/hipl/whitelisting into lp:hipl.
>
> --- hipd/netdev.c 2011-05-25 09:22:19 +0000
> +++ hipd/netdev.c 2011-08-11 11:48:38 +0000
> @@ -99,19 +99,27 @@
> if (hip_netdev_white_list_count < HIP_NETDEV_MAX_WHITE_LIST) {
> - hip_netdev_white_list[hip_netdev_white_list_count++] = if_index;
> + hip_netdev_white_list[hip_netdev_white_list_count].if_index = if_index;
> + strncpy(hip_netdev_white_list[hip_netdev_white_list_count].if_label, device_name, sizeof(hip_netdev_white_list[0].if_label) - 1);

This is an opportunity for breaking a line, as is

> @@ -119,17 +127,20 @@
>
> -static int hip_netdev_is_in_white_list(int if_index)
> +static int hip_netdev_is_in_white_list(const unsigned int if_index, const char *const device_name)

this one

> + if (hip_netdev_white_list_count > 0) {
> + for (unsigned int i = 0; i < hip_netdev_white_list_count; i++) {
> + if (hip_netdev_white_list[i].if_index == if_index &&
> + !strncmp(hip_netdev_white_list[i].if_label, device_name, sizeof(hip_netdev_white_list[0].if_label))) {

and this one.

> @@ -1122,6 +1132,40 @@
>
> /**
> + * This functions gives you the interface label for a given IPv4 or IPv6 address.

This sentence explains why starting a sentence with "this sentence" is
redundant and weird.

> + * @param addr address for which you want to know the label
> + * @param label pointer where the function stores the label
> + * @return one on success, zero on error and write the label in param label
> + * if the given addr exists in the system

address

The usual convention is to return zero on success, not one.

> +int hip_find_label_for_address(const struct sockaddr *const addr, char *const label)

long line

> +{
> + int res = 0;
> + struct ifaddrs *myaddrs, *ifa = NULL;
> +
> + getifaddrs(&myaddrs);
> + for (ifa = myaddrs; ifa != NULL; ifa = ifa->ifa_next) {
> + if (ifa->ifa_addr == NULL ||
> + (ifa->ifa_addr->sa_family != AF_INET && ifa->ifa_addr->sa_family != AF_INET6)) {

long line

> @@ -1213,6 +1252,18 @@
>
> + /* find interface label for address and check if it is whitelisted or not */
> + if (is_add) {
> + char label[IF_NAMESIZE];
> + if (hip_find_label_for_address(addr, label)) {
> + if ((!hip_netdev_is_in_white_list(ifa->ifa_index, label))) {
> + HIP_DEBUG("Interface:<%s> is not whitelisted\n", label);
> + continue;

The conditions can be merged.

> --- hipd/netdev.h 2011-05-18 15:12:07 +0000
> +++ hipd/netdev.h 2011-08-11 11:48:38 +0000
> @@ -56,4 +56,6 @@
>
> +int hip_find_label_for_address(const struct sockaddr *const addr, char *const label);

long line

Diego

review: Needs Fixing
Revision history for this message
Christian Röller (christian-roeller) wrote : Posted in a previous version of this proposal
Download full text (3.2 KiB)

> review needs-fixing
>
> On Thu, Aug 11, 2011 at 11:48:47AM +0000, Christian Röller wrote:
> > Christian Röller has proposed merging lp:~christian-
> roeller/hipl/whitelisting into lp:hipl.
> >
> > --- hipd/netdev.c 2011-05-25 09:22:19 +0000
> > +++ hipd/netdev.c 2011-08-11 11:48:38 +0000
> > @@ -99,19 +99,27 @@
> > if (hip_netdev_white_list_count < HIP_NETDEV_MAX_WHITE_LIST) {
> > - hip_netdev_white_list[hip_netdev_white_list_count++] = if_index;
> > + hip_netdev_white_list[hip_netdev_white_list_count].if_index =
> if_index;
> > +
> strncpy(hip_netdev_white_list[hip_netdev_white_list_count].if_label,
> device_name, sizeof(hip_netdev_white_list[0].if_label) - 1);
>
> This is an opportunity for breaking a line, as is
>
> > @@ -119,17 +127,20 @@
> >
> > -static int hip_netdev_is_in_white_list(int if_index)
> > +static int hip_netdev_is_in_white_list(const unsigned int if_index, const
> char *const device_name)
>
> this one
>
> > + if (hip_netdev_white_list_count > 0) {
> > + for (unsigned int i = 0; i < hip_netdev_white_list_count; i++) {
> > + if (hip_netdev_white_list[i].if_index == if_index &&
> > + !strncmp(hip_netdev_white_list[i].if_label, device_name,
> sizeof(hip_netdev_white_list[0].if_label))) {
>
> and this one.
>
> > @@ -1122,6 +1132,40 @@
> >
> > /**
> > + * This functions gives you the interface label for a given IPv4 or IPv6
> address.
>
> This sentence explains why starting a sentence with "this sentence" is
> redundant and weird.
>
> > + * @param addr address for which you want to know the label
> > + * @param label pointer where the function stores the label
> > + * @return one on success, zero on error and write the label in param label
> > + * if the given addr exists in the system
>
> address
>
> The usual convention is to return zero on success, not one.
>
> > +int hip_find_label_for_address(const struct sockaddr *const addr, char
> *const label)
>
> long line
>
> > +{
> > + int res = 0;
> > + struct ifaddrs *myaddrs, *ifa = NULL;
> > +
> > + getifaddrs(&myaddrs);
> > + for (ifa = myaddrs; ifa != NULL; ifa = ifa->ifa_next) {
> > + if (ifa->ifa_addr == NULL ||
> > + (ifa->ifa_addr->sa_family != AF_INET &&
> ifa->ifa_addr->sa_family != AF_INET6)) {
>
> long line
>
> > @@ -1213,6 +1252,18 @@
> >
> > + /* find interface label for address and check if it is
> whitelisted or not */
> > + if (is_add) {
> > + char label[IF_NAMESIZE];
> > + if (hip_find_label_for_address(addr, label)) {
> > + if ((!hip_netdev_is_in_white_list(ifa->ifa_index,
> label))) {
> > + HIP_DEBUG("Interface:<%s> is not whitelisted\n",
> label);
> > + continue;
>
> The conditions can be merged.
>
> > --- hipd/netdev.h 2011-05-18 15:12:07 +0000
> > +++ hipd/netdev.h 2011-08-11 11:48:38 +0000
> > @@ -56,4 +56,6 @@
> >
> > +int hip_find_label_for_address(const struct sockaddr *const addr, char
> *const label);
>
> long line
>
> Diego

Everything done...
I also adapt the autobuild script to my local system conditi...

Read more...

Revision history for this message
Stefan Götz (stefan.goetz-deactivatedaccount) wrote : Posted in a previous version of this proposal

Hi Christian!

Sorry for coming back late with required fixes :-(

> /**
> + * Gives you the interface label for a given IPv4 or IPv6 address.
> + *
> + * @param addr address for which you want to know the label
> + * @param label pointer where the function stores the label
> + * @return zero on success, one on error and write the label in param label
> + * if the given address exists in the system
> + */
> +int hip_find_label_for_address(const struct sockaddr *const addr,
> + char *const label)

[M] safety: this function is not very safe in how it handles the length of the memory buffer pointed to by 'label'. Please either document clearly how large the memory buffer needs to be and what happens if it is not or add code that helps to avoid buffer overflows here.

[M] policy: since this is a new function, it needs to be checked by a unit test. I know it's a PITA but unit tests, for example, immediately point to such issues as the memory buffer handling.

Regards,
 Stefan

review: Needs Fixing
Revision history for this message
Christian Röller (christian-roeller) wrote : Posted in a previous version of this proposal

> Hi Christian!

Hi

>
> Sorry for coming back late with required fixes :-(

no problem...

>
> > /**
> > + * Gives you the interface label for a given IPv4 or IPv6 address.
> > + *
> > + * @param addr address for which you want to know the label
> > + * @param label pointer where the function stores the label
> > + * @return zero on success, one on error and write the label in param label
> > + * if the given address exists in the system
> > + */
> > +int hip_find_label_for_address(const struct sockaddr *const addr,
> > + char *const label)
>
> [M] safety: this function is not very safe in how it handles the length of the
> memory buffer pointed to by 'label'. Please either document clearly how large
> the memory buffer needs to be and what happens if it is not or add code that
> helps to avoid buffer overflows here.

What is exactly the safety problem here? Do you mean I should additionally mention that label
sould be at least as big as IF_NAMESIZE, so that every possible interfacelabel length would fit?
Because right now I check whether the found interfacelabel is not bigger than the associated memory for label. And only if this is the case I will write to label. And I never write more than sizeof(label) bytes to label. Is this not enough to avoid a buffer overflow?
Right now the function will just return 1 if label would be to small. Maybe I should introduce here a special return value to make the debugging easier for the caller. What do you think?

>
> [M] policy: since this is a new function, it needs to be checked by a unit
> test. I know it's a PITA but unit tests, for example, immediately point to
> such issues as the memory buffer handling.
>
> Regards,
> Stefan

Christian

Revision history for this message
Stefan Götz (stefan.goetz-deactivatedaccount) wrote : Posted in a previous version of this proposal

Hi Christian!

> > > +int hip_find_label_for_address(const struct sockaddr *const addr,
> > > + char *const label)
> >
> > [M] safety: this function is not very safe in how it handles the length of
[...]
>
> What is exactly the safety problem here?

Nothing - sorry, I simply misread the code.

Stefan

Revision history for this message
Diego Biurrun (diego-biurrun) wrote : Posted in a previous version of this proposal

 review needs-fixing

On Mon, Aug 22, 2011 at 11:47:44AM +0000, Christian Röller wrote:
> Christian Röller has proposed merging lp:~christian-roeller/hipl/whitelisting into lp:hipl.

The word is "whitelist", not "white list". This is not exactly very
important, but since you are changing some parts of it, you might fix it
on the lines you are touching anyway.

> --- hipd/netdev.c 2011-08-15 14:11:56 +0000
> +++ hipd/netdev.c 2011-08-22 11:47:21 +0000
> @@ -97,19 +97,28 @@
> -static int hip_netdev_white_list[HIP_NETDEV_MAX_WHITE_LIST];
> -static int hip_netdev_white_list_count = 0;
> +struct hip_netdev_whiteliste_entry {
> + unsigned int if_index;
> + char if_label[IF_NAMESIZE];
> +};
> +static struct hip_netdev_whiteliste_entry hip_netdev_white_list[HIP_NETDEV_MAX_WHITE_LIST];
> +static unsigned int hip_netdev_white_list_count = 0;

whitelist, not whitelistE

> /**
> - * Add a network interface index number to the list of white listed
> + * Add a network interface index number plus label to the list of white listed

whitelisted

> * @param if_index the network interface index to be white listed
> + * @param device_name the network interface label to be white listed

whitelisted

> */
> -static void hip_netdev_white_list_add_index(int if_index)
> +static void hip_netdev_white_list_add_index_and_name(const unsigned int if_index,
> + const char *const device_name)

whitelist

> @@ -117,17 +126,22 @@
>
> /**
> - * Test if the given network interface index is white listed.
> + * Test if the given network interface index plus label is white listed.

whitelisted

> @@ -1120,6 +1133,40 @@
>
> /**
> + * Gives you the interface label for a given IPv4 or IPv6 address.
> + *
> + * @param addr address for which you want to know the label
> + * @param label pointer where the function stores the label

nit: please vertically align the descriptions.

Diego

review: Needs Fixing
Revision history for this message
Christian Röller (christian-roeller) wrote : Posted in a previous version of this proposal

> review needs-fixing
>
> On Mon, Aug 22, 2011 at 11:47:44AM +0000, Christian Röller wrote:
> > Christian Röller has proposed merging lp:~christian-
> roeller/hipl/whitelisting into lp:hipl.
>
> The word is "whitelist", not "white list". This is not exactly very
> important, but since you are changing some parts of it, you might fix it
> on the lines you are touching anyway.
>
> > --- hipd/netdev.c 2011-08-15 14:11:56 +0000
> > +++ hipd/netdev.c 2011-08-22 11:47:21 +0000
> > @@ -97,19 +97,28 @@
> > -static int hip_netdev_white_list[HIP_NETDEV_MAX_WHITE_LIST];
> > -static int hip_netdev_white_list_count = 0;
> > +struct hip_netdev_whiteliste_entry {
> > + unsigned int if_index;
> > + char if_label[IF_NAMESIZE];
> > +};
> > +static struct hip_netdev_whiteliste_entry
> hip_netdev_white_list[HIP_NETDEV_MAX_WHITE_LIST];
> > +static unsigned int hip_netdev_white_list_count = 0;
>
> whitelist, not whitelistE
>
> > /**
> > - * Add a network interface index number to the list of white listed
> > + * Add a network interface index number plus label to the list of white
> listed
>
> whitelisted
>
> > * @param if_index the network interface index to be white listed
> > + * @param device_name the network interface label to be white listed
>
> whitelisted
>
> > */
> > -static void hip_netdev_white_list_add_index(int if_index)
> > +static void hip_netdev_white_list_add_index_and_name(const unsigned int
> if_index,
> > + const char *const
> device_name)
>
> whitelist
>
> > @@ -117,17 +126,22 @@
> >
> > /**
> > - * Test if the given network interface index is white listed.
> > + * Test if the given network interface index plus label is white listed.
>
> whitelisted
>
> > @@ -1120,6 +1133,40 @@
> >
> > /**
> > + * Gives you the interface label for a given IPv4 or IPv6 address.
> > + *
> > + * @param addr address for which you want to know the label
> > + * @param label pointer where the function stores the label
>
> nit: please vertically align the descriptions.
>
> Diego

Correct the typos...

Christian

Revision history for this message
Diego Biurrun (diego-biurrun) wrote : Posted in a previous version of this proposal

 review approve

On Mon, Aug 22, 2011 at 07:05:35PM +0000, Christian Röller wrote:
> Christian Röller has proposed merging lp:~christian-roeller/hipl/whitelisting into lp:hipl.
>
> --- hipd/netdev.c 2011-08-15 14:11:56 +0000
> +++ hipd/netdev.c 2011-08-22 19:05:27 +0000
> @@ -1120,6 +1133,40 @@
> }
>
> /**
> + * Gives you the interface label for a given IPv4 or IPv6 address.
> + *
> + * @param addr address for which you want to know the label
> + * @param label pointer where the function stores the label
> + * @return zero on success, one on error and write the label
> + * in param label if the given address exists in the system

What I tried to suggest here was that you could vertically align the
descriptions, i.e.

  * @param addr address for which you want to know the label
  * @param label pointer where the function stores the label

Witness how "address" and "pointer" start on the same column.
Feel free to implement or ignore this nitpick at your discretion.

Diego

review: Approve
Revision history for this message
René Hummen (rene-hummen) wrote : Posted in a previous version of this proposal
Download full text (3.5 KiB)

Hi,

I just got one issue that was raised by Stefan before, but has not been fixed so far (more inline).

On 22.08.2011, at 21:05, Christian Röller wrote:
> Christian Röller has proposed merging lp:~christian-roeller/hipl/whitelisting into lp:hipl.
>
> Requested reviews:
> Stefan Götz (stefan.goetz)
> Diego Biurrun (diego-biurrun)
>
> For more details, see:
> https://code.launchpad.net/~christian-roeller/hipl/whitelisting/+merge/72487

> /**
> - * Add a network interface index number to the list of white listed
> + * Add a network interface index number plus label to the list of whitelisted
> * network interfaces.
> *
> - * @param if_index the network interface index to be white listed
> + * @param if_index the network interface index to be whitelisted
> + * @param device_name the network interface label to be whitelisted
> */
> -static void hip_netdev_white_list_add_index(int if_index)
> +static void hip_netdev_white_list_add_index_and_name(const unsigned int if_index,
> + const char *const device_name)
> {
> if (hip_netdev_white_list_count < HIP_NETDEV_MAX_WHITE_LIST) {
> - hip_netdev_white_list[hip_netdev_white_list_count++] = if_index;
> + hip_netdev_white_list[hip_netdev_white_list_count].if_index = if_index;
> + strncpy(hip_netdev_white_list[hip_netdev_white_list_count].if_label,
> + device_name, sizeof(hip_netdev_white_list[0].if_label) - 1);

Why don't you strncpy the complete sizeof? Either the string is null-terminated, in which case you should copy the 0 as well, or it is not, in which case you will miss the last letter of the label. What happens with label is of length 1?

> /**
> - * Add a network interface index number to the list of white listed
> + * Add a network interface index number to the list of whitelisted
> * network interfaces by name.
> *
> - * @param device_name the name of the device to be white listed
> + * @param device_name the name of the device to be whitelisted
> * @return 1 on success, 0 on error
> */
> int hip_netdev_white_list_add(const char *const device_name)
> @@ -146,19 +160,18 @@
> int sock = 0;
> int ret = 0;
>
> - strncpy(ifr.ifr_name, device_name, IF_NAMESIZE);
> + strncpy(ifr.ifr_name, device_name, sizeof(ifr.ifr_name) - 1);

Same here.

> /**
> + * Gives you the interface label for a given IPv4 or IPv6 address.
> + *
> + * @param addr address for which you want to know the label
> + * @param label pointer where the function stores the label
> + * @return zero on success, one on error and write the label
> + * in param label if the given address exists in the system
> + */
> +int hip_find_label_for_address(const struct sockaddr *const addr,
> + char *const label)
> +{
> + int res = 1;
> + struct ifaddrs *myaddrs, *ifa = NULL;
> +
> + getifaddrs(&myaddrs);
> + for (ifa = myaddrs; ifa != NULL; ifa = ifa->ifa_next) {
> + if (ifa->ifa_addr == NULL ||
> + (ifa->ifa_addr->sa_family != AF_INET &&
> + ifa->ifa_addr->sa_family != AF_INET6)) {
> + continue;
> + }
>...

Read more...

Revision history for this message
René Hummen (rene-hummen) : Posted in a previous version of this proposal
review: Needs Information
Revision history for this message
Christian Röller (christian-roeller) wrote : Posted in a previous version of this proposal
Download full text (5.3 KiB)

> Hi,
>
> I just got one issue that was raised by Stefan before, but has not been fixed
> so far (more inline).
>
> On 22.08.2011, at 21:05, Christian Röller wrote:
> > Christian Röller has proposed merging lp:~christian-
> roeller/hipl/whitelisting into lp:hipl.
> >
> > Requested reviews:
> > Stefan Götz (stefan.goetz)
> > Diego Biurrun (diego-biurrun)
> >
> > For more details, see:
> > https://code.launchpad.net/~christian-roeller/hipl/whitelisting/+merge/72487
>
> > /**
> > - * Add a network interface index number to the list of white listed
> > + * Add a network interface index number plus label to the list of
> whitelisted
> > * network interfaces.
> > *
> > - * @param if_index the network interface index to be white listed
> > + * @param if_index the network interface index to be whitelisted
> > + * @param device_name the network interface label to be whitelisted
> > */
> > -static void hip_netdev_white_list_add_index(int if_index)
> > +static void hip_netdev_white_list_add_index_and_name(const unsigned int
> if_index,
> > + const char *const
> device_name)
> > {
> > if (hip_netdev_white_list_count < HIP_NETDEV_MAX_WHITE_LIST) {
> > - hip_netdev_white_list[hip_netdev_white_list_count++] = if_index;
> > + hip_netdev_white_list[hip_netdev_white_list_count].if_index =
> if_index;
> > +
> strncpy(hip_netdev_white_list[hip_netdev_white_list_count].if_label,
> > + device_name, sizeof(hip_netdev_white_list[0].if_label) -
> 1);
>
> Why don't you strncpy the complete sizeof? Either the string is null-
> terminated, in which case you should copy the 0 as well, or it is not, in
> which case you will miss the last letter of the label. What happens with label
> is of length 1?

Yes, you are right, I should definitly use the complete sizeof here. But it is always the same with
strncpy. Either it only copies the start of the string if the source is too long or it fills up
the destination with zeros, which is actually time wasting. But I think the more worse problem is to
have no null-termination, which would be the case if device_name will be exactly as big as IF_NAMESIZE.
So I should maybe increase:

struct hip_netdev_whitelist_entry {
    unsigned int if_index;
- char if_label[IF_NAMESIZE];
+ char if_label[IF_NAMESIZE+1];
};

to guarantee a null-termination. If we assume, that device_name is not bigger than IF_NAMESIZE, which we could/should check in function hip_netdev_white_list_add. See below...
>
> > /**
> > - * Add a network interface index number to the list of white listed
> > + * Add a network interface index number to the list of whitelisted
> > * network interfaces by name.
> > *
> > - * @param device_name the name of the device to be white listed
> > + * @param device_name the name of the device to be whitelisted
> > * @return 1 on success, 0 on error
> > */
> > int hip_netdev_white_list_add(const char *const device_name)
> > @@ -146,19 +160,18 @@
> > int sock = 0;
> > int ret = 0;
> >
> > - strncpy(ifr.ifr_name, device_name, IF_NAMESIZE);
> > + strncpy(ifr.ifr_name, device_name, sizeof...

Read more...

Revision history for this message
Stefan Götz (stefan.goetz-deactivatedaccount) wrote : Posted in a previous version of this proposal

Hi Christian!

> +int hip_find_label_for_address(const struct sockaddr *const addr,
> + char *const label)

[M] policy: since this is a new function, it needs to be checked by a unit test.

Regards,
 Stefan

review: Needs Fixing
Revision history for this message
Christian Röller (christian-roeller) wrote : Posted in a previous version of this proposal
Download full text (6.0 KiB)

Hi,

sorry for the confusion.
I have just found out,that IF_NAMESIZE is big enough to fit the max. interface
name length plus null-termination. So with Rene's suggested change of using sizeof(*) instead of sizeof(* - 1) it is fine and guarantee a null-termination.

Christian

> > Hi,
> >
> > I just got one issue that was raised by Stefan before, but has not been
> fixed
> > so far (more inline).
> >
> > On 22.08.2011, at 21:05, Christian Röller wrote:
> > > Christian Röller has proposed merging lp:~christian-
> > roeller/hipl/whitelisting into lp:hipl.
> > >
> > > Requested reviews:
> > > Stefan Götz (stefan.goetz)
> > > Diego Biurrun (diego-biurrun)
> > >
> > > For more details, see:
> > > https://code.launchpad.net/~christian-
> roeller/hipl/whitelisting/+merge/72487
> >
> > > /**
> > > - * Add a network interface index number to the list of white listed
> > > + * Add a network interface index number plus label to the list of
> > whitelisted
> > > * network interfaces.
> > > *
> > > - * @param if_index the network interface index to be white listed
> > > + * @param if_index the network interface index to be whitelisted
> > > + * @param device_name the network interface label to be whitelisted
> > > */
> > > -static void hip_netdev_white_list_add_index(int if_index)
> > > +static void hip_netdev_white_list_add_index_and_name(const unsigned int
> > if_index,
> > > + const char *const
> > device_name)
> > > {
> > > if (hip_netdev_white_list_count < HIP_NETDEV_MAX_WHITE_LIST) {
> > > - hip_netdev_white_list[hip_netdev_white_list_count++] = if_index;
> > > + hip_netdev_white_list[hip_netdev_white_list_count].if_index =
> > if_index;
> > > +
> > strncpy(hip_netdev_white_list[hip_netdev_white_list_count].if_label,
> > > + device_name, sizeof(hip_netdev_white_list[0].if_label) -
> > 1);
> >
> > Why don't you strncpy the complete sizeof? Either the string is null-
> > terminated, in which case you should copy the 0 as well, or it is not, in
> > which case you will miss the last letter of the label. What happens with
> label
> > is of length 1?
>
> Yes, you are right, I should definitly use the complete sizeof here. But it is
> always the same with
> strncpy. Either it only copies the start of the string if the source is too
> long or it fills up
> the destination with zeros, which is actually time wasting. But I think the
> more worse problem is to
> have no null-termination, which would be the case if device_name will be
> exactly as big as IF_NAMESIZE.
> So I should maybe increase:
>
> struct hip_netdev_whitelist_entry {
> unsigned int if_index;
> - char if_label[IF_NAMESIZE];
> + char if_label[IF_NAMESIZE+1];
> };
>
> to guarantee a null-termination. If we assume, that device_name is not bigger
> than IF_NAMESIZE, which we could/should check in function
> hip_netdev_white_list_add. See below...
> >
> > > /**
> > > - * Add a network interface index number to the list of white listed
> > > + * Add a network interface index number to the list of whitelisted
> > > * network interfaces by name.
> > > *
> > > - * @param device_name...

Read more...

Revision history for this message
Christian Röller (christian-roeller) wrote : Posted in a previous version of this proposal

I have added the unit tests for the new function.

Regarding this I have updated the branch to have a latest code version and edit the Makefile.am to let the tests compile.

Additionally it occurs to me, that I have to change the hip_find_label_for_address function, because the "sizeof-check", I did before to determine the size of the passed label parameter, turns out to be pointless. For that reason I added a new parameter to the function, which indicates the size of the passed char pointer.

This will maybe not solve the problem of a buffer overflow, because the responsibility of the value of the new parameter is based on the programmer, but it could be helpful to not forget to choose the value big enough.

Just tell me what you think about it...

Revision history for this message
Christof Mroz (christof-mroz) wrote : Posted in a previous version of this proposal
Download full text (5.4 KiB)

Most of the following are just suggestions, though there's one stopper.

> -static void hip_netdev_white_list_add_index(int if_index)
> +static void hip_netdev_white_list_add_index_and_name(const unsigned int if_index,
> + const char *const device_name)
> {
> if (hip_netdev_white_list_count < HIP_NETDEV_MAX_WHITE_LIST) {
> - hip_netdev_white_list[hip_netdev_white_list_count++] = if_index;
> + hip_netdev_white_list[hip_netdev_white_list_count].if_index = if_index;
> + strncpy(hip_netdev_white_list[hip_netdev_white_list_count].if_label,
> + device_name, sizeof(hip_netdev_white_list[0].if_label));
> + hip_netdev_white_list_count++;

Sorry to bring up this issue again :)

I suspect you already know that the strncpy() may leave you with an
unterminated if_label here, and you're betting on a sensible length of
device_name. See e.g. [1] for an explanation.
It's always a good idea to add an assert() when gambling, for the sole
purpose of documentation if anything. But better still, I'd terminate
the string explicitly.

If I'm mistaken here, please comment the code (or the device_name
parameter) to clarify. Audit all the other instances of strncpy() you
touched, too.

Also, dropping the hip_netdev_ prefix, at least for static identifiers,
looks safe to me and it would vastly shorten line lengths everywhere in
this file.

[1] http://stackoverflow.com/questions/1453876/why-does-strncpy-not-null-terminate

> + if (hip_netdev_white_list_count > 0) {
> + for (unsigned int i = 0; i < hip_netdev_white_list_count; i++) {
> + if (hip_netdev_white_list[i].if_index == if_index &&
> + !strncmp(hip_netdev_white_list[i].if_label,
> + device_name, sizeof(hip_netdev_white_list[0].if_label))) {
> + return 1;
> + }
> }
> }

Drop the outer if(...): This check is performed on the first for(...) iteration
anyway.

     return 0;
 }

> /**
> - * Add a network interface index number to the list of white listed
> + * Add a network interface index number to the list of whitelisted
> * network interfaces by name.
> *

You replaced `white list' with `whitelist' in comments, so you should
change it in identifiers as well: `white_list' -> `whitelist'.

> /**
> + * Gives you the interface label for a given IPv4 or IPv6 address.

`Gives you' -> `Returns'

> + *
> + * @param addr Address for which you want to know the label
> + * @param label Pointer where the function stores the label.
> + * @param sizeoflabel Size of the passed label parameter, should be chosen big enough
> + * to be able to store every possible interface name plus null-termination.
> + * @return Zero on success, one on error and write the label
> + * in param label if the given address exists in the system.
> + * Label will be null terminated for sure, iff param label
> + * is chosen big enough(IF_NAMESIZE == 16).
> + */

I'...

Read more...

review: Needs Fixing
Revision history for this message
Christian Röller (christian-roeller) wrote : Posted in a previous version of this proposal
Download full text (7.6 KiB)

> Most of the following are just suggestions, though there's one stopper.
>
> > -static void hip_netdev_white_list_add_index(int if_index)
> > +static void hip_netdev_white_list_add_index_and_name(const unsigned int
> if_index,
> > + const char *const
> device_name)
> > {
> > if (hip_netdev_white_list_count < HIP_NETDEV_MAX_WHITE_LIST) {
> > - hip_netdev_white_list[hip_netdev_white_list_count++] = if_index;
> > + hip_netdev_white_list[hip_netdev_white_list_count].if_index =
> if_index;
> > +
> strncpy(hip_netdev_white_list[hip_netdev_white_list_count].if_label,
> > + device_name, sizeof(hip_netdev_white_list[0].if_label));
> > + hip_netdev_white_list_count++;
>
> Sorry to bring up this issue again :)
>
> I suspect you already know that the strncpy() may leave you with an
> unterminated if_label here, and you're betting on a sensible length of
> device_name. See e.g. [1] for an explanation.
> It's always a good idea to add an assert() when gambling, for the sole
> purpose of documentation if anything. But better still, I'd terminate
> the string explicitly.
>
> If I'm mistaken here, please comment the code (or the device_name
> parameter) to clarify. Audit all the other instances of strncpy() you
> touched, too.

Actually you are right, but in this case the null-termination is guaranteed.
Because the max interface name length in linux is 15 and I am allocating 16 byte(IF_NAMESIZE)
for my hip_netdev_whitelist_entry struct. And in strncpy I always write IF_NAMESIZE many bytes,
so even in the case our system has a maximum interface name of 15, I would write at least one byte
more and terminate the string in this manner, because strncpy would fill up the buffer with nulls.
So if_label has at least one null-termination, possibly more. I know this is not the definition of
a c-string with only one null-termination at the end, but actually this should not result in any problems. If I am wrong please correct me...

>
> Also, dropping the hip_netdev_ prefix, at least for static identifiers,
> looks safe to me and it would vastly shorten line lengths everywhere in
> this file.

Yes of course I can do it, thats because I didn't write this function I just adopt them.
So I tried to change as few as possible.

>
> [1] http://stackoverflow.com/questions/1453876/why-does-strncpy-not-null-
> terminate
>
> > + if (hip_netdev_white_list_count > 0) {
> > + for (unsigned int i = 0; i < hip_netdev_white_list_count; i++) {
> > + if (hip_netdev_white_list[i].if_index == if_index &&
> > + !strncmp(hip_netdev_white_list[i].if_label,
> > + device_name,
> sizeof(hip_netdev_white_list[0].if_label))) {
> > + return 1;
> > + }
> > }
> > }
>
> Drop the outer if(...): This check is performed on the first for(...)
> iteration
> anyway.

Same here I guess this was the actual auther of the function, but of course you are right this is duplicative. I just don't see it...

>
> return 0;
> }
>
> > /**
> > - * Add a network interface index number to the list of white listed...

Read more...

Revision history for this message
Christof Mroz (christof-mroz) wrote : Posted in a previous version of this proposal
Download full text (4.2 KiB)

On Tue, 13 Sep 2011 19:43:28 +0200, Christian Röller
<email address hidden> wrote:

> Because the max interface name length in linux is 15 and I am
> allocating 16 byte(IF_NAMESIZE) for my hip_netdev_whitelist_entry
> struct. And in strncpy I always write IF_NAMESIZE many bytes, so even
> in the case our system has a maximum interface name of 15, I would
> write at least one byte more and terminate the string in this manner,
> because strncpy would fill up the buffer with nulls.

Unless device_name points to a string that's bigger than the allowed
interface name. Consider the following minimal example:

char dst[2]; // expected to hold a one-character "string"
char src[] = "ab"; // too long
strncpy(dst, src, sizeof(dst)); // dst not NULL terminated

Now if you checked the length already (in the calling function, for
example), of course you can safely assume that the supplied string is
not too long. In order to communicate your assumption to fellow
programmers, add an assertion:

assert(strlen(device_name) < sizeof(whitelist[0].if_label))

If you didn't check the length beforehand however, you need to display
an error message and exit gracefully because the interface name is a
user-supplied value. Assertions are reserved for "programmer-supplied"
values, you could say.

> So if_label has at least one null-termination, possibly more. I know
> this is not the definition of a c-string with only one
> null-termination at the end, but actually this should not result in
> any problems. If I am wrong please correct me...

No you're right, multiple \0 bytes don't matter.

>> Also, dropping the hip_netdev_ prefix, at least for static identifiers,
>> looks safe to me and it would vastly shorten line lengths everywhere in
>> this file.
>
> Yes of course I can do it, thats because I didn't write this function I
> just adopt them.
> So I tried to change as few as possible.

Of course; if at all, this should be done in a designated branch since
the diff will be huge.

>> You replaced `white list' with `whitelist' in comments, so you should
>> change it in identifiers as well: `white_list' -> `whitelist'.
>
> Again a case of adoption, the actual author use this syntax, so I adopt
> it.
> This change was more the grammar owed, which should be adhered to in
> comments more than for variable names. ;-) But I can change it of
> course lets see what the others think about it...

Changing the comments was off-topic to begin with, so I'd be for
finishing it (unless someone objects)

>> I'd say it's reasonable to require `sizeof(label) >= IF_NAMESIZE' in the
>> documentation and drop the sizeoflabel parameter. Note that you can
>> specify
>>
>> int hip_find_label_for_address(const struct sockaddr *const addr,
>> char label[IF_NAMESIZE])
>>
>> to enable a minimal compile-time check (at least for statically
>> allocated buffers. Hey, better than nothing).
>
> Yes you are right, but to make use of it we need a statically allocated
> buffer, which we use for calling this function. This would only make
> sense if the function itself is static, right?

Maybe static wasn't the right term... I rather meant a "...

Read more...

Revision history for this message
Christian Röller (christian-roeller) wrote : Posted in a previous version of this proposal
Download full text (5.9 KiB)

> On Tue, 13 Sep 2011 19:43:28 +0200, Christian Röller
> <email address hidden> wrote:
>
> > Because the max interface name length in linux is 15 and I am
> > allocating 16 byte(IF_NAMESIZE) for my hip_netdev_whitelist_entry
> > struct. And in strncpy I always write IF_NAMESIZE many bytes, so even
> > in the case our system has a maximum interface name of 15, I would
> > write at least one byte more and terminate the string in this manner,
> > because strncpy would fill up the buffer with nulls.
>
> Unless device_name points to a string that's bigger than the allowed
> interface name. Consider the following minimal example:
>
> char dst[2]; // expected to hold a one-character "string"
> char src[] = "ab"; // too long
> strncpy(dst, src, sizeof(dst)); // dst not NULL terminated
>
> Now if you checked the length already (in the calling function, for
> example), of course you can safely assume that the supplied string is
> not too long. In order to communicate your assumption to fellow
> programmers, add an assertion:
>
> assert(strlen(device_name) < sizeof(whitelist[0].if_label))
>
> If you didn't check the length beforehand however, you need to display
> an error message and exit gracefully because the interface name is a
> user-supplied value. Assertions are reserved for "programmer-supplied"
> values, you could say.

Yes, you are right I should somehow communicate this. I just want to say that it is not possible
to have here no null-termination, because device_name(src) is at most 15 and
hip_netdev_white_list[hip_netdev_white_list_count].if_label(dst) is 16 and I will write 16 bytes.
You are right the interface name, which should be whitelisted is user-supplied, but the hip_netdev_white_list_add_index_and_name function is only called if the interface name is really existing in the system. So it's valid, which would be only the case if it will be smaller than 16.
But you are right, this is maybe not directly obvious. But I think to comment this in the function
is enough, because an assertion would mean additional computations, which are not necessary because the assertion would never fire.

>
> > So if_label has at least one null-termination, possibly more. I know
> > this is not the definition of a c-string with only one
> > null-termination at the end, but actually this should not result in
> > any problems. If I am wrong please correct me...
>
> No you're right, multiple \0 bytes don't matter.
>
> >> Also, dropping the hip_netdev_ prefix, at least for static identifiers,
> >> looks safe to me and it would vastly shorten line lengths everywhere in
> >> this file.
> >
> > Yes of course I can do it, thats because I didn't write this function I
> > just adopt them.
> > So I tried to change as few as possible.
>
> Of course; if at all, this should be done in a designated branch since
> the diff will be huge.
>
> >> You replaced `white list' with `whitelist' in comments, so you should
> >> change it in identifiers as well: `white_list' -> `whitelist'.
> >
> > Again a case of adoption, the actual author use this syntax, so I adopt
> > it.
> > This change was more the grammar owed, which should be adhered to in
...

Read more...

Revision history for this message
Christof Mroz (christof-mroz) wrote : Posted in a previous version of this proposal

On Tue, 13 Sep 2011 21:09:23 +0200, Christian Röller
<email address hidden> wrote:

> But I think to comment this in the function is enough, because an
> assertion would mean additional computations, which are not necessary
> because the assertion would never fire.

That's the point of using an assertion versus a regular check: if
performance matters (in release builds etc.), you should be able to
undef the HIP_ASSERT macro (and thus don't compile the checks) without
breaking anything. In this sense, assertions don't cost anything.

> I tried this and the compiler doesn't complain. I could choose every
> size vor char label[].
> Are you sure, that this will be checked from the compiler? I think
> this would only be the case, if I will really declare label as
> static. Because only these variables are known to the compiler during
> the compilephase. For label[IF_NAMESIZE] will first memory allocated
> during the execution. Maybe this is the reason why the compiler
> doesn't complain. Although I would say this must be verifiable during
> the compilephase. But I am not sure if the compiler will do it.
> But maybe I am totaly wrong here. What would you say?

Just tried it myself, and you're right: no sanity checks when passing
buffers around. Not even bounds checking works for parameter arrays;
it's as if the size info is discarded altogether. Which can't be true
because the compiler needs to carry it around for multidimensional
arrays, where all but one dimension must be specified. Meh, never
trust compilers...

Why did I think it would work in the first place? Because gcc actually
does (static, i.e. no-cost) bounds-checking e.g. for stack-allocated
arrays if told so. But Parameters are a whole other affair, it seems.

That said: feel free to omit the size, though I'd say it improves
documentation.

Revision history for this message
Diego Biurrun (diego-biurrun) wrote : Posted in a previous version of this proposal

On Tue, Sep 13, 2011 at 05:43:28PM +0000, Christian Röller wrote:
> > Most of the following are just suggestions, though there's one stopper.
> >
> > > -static void hip_netdev_white_list_add_index(int if_index)
> > > +static void hip_netdev_white_list_add_index_and_name(const unsigned int
> > if_index,
> > > + const char *const
> > device_name)
> > > {
> > > if (hip_netdev_white_list_count < HIP_NETDEV_MAX_WHITE_LIST) {
> > > - hip_netdev_white_list[hip_netdev_white_list_count++] = if_index;
> > > + hip_netdev_white_list[hip_netdev_white_list_count].if_index =
> > if_index;
> > > +
> > strncpy(hip_netdev_white_list[hip_netdev_white_list_count].if_label,
> > > + device_name, sizeof(hip_netdev_white_list[0].if_label));
> > > + hip_netdev_white_list_count++;
> >
> > Sorry to bring up this issue again :)
> >
> > I suspect you already know that the strncpy() may leave you with an
> > unterminated if_label here, and you're betting on a sensible length of
> > device_name. See e.g. [1] for an explanation.
> > It's always a good idea to add an assert() when gambling, for the sole
> > purpose of documentation if anything. But better still, I'd terminate
> > the string explicitly.
> >
> > If I'm mistaken here, please comment the code (or the device_name
> > parameter) to clarify. Audit all the other instances of strncpy() you
> > touched, too.
>
> Actually you are right, but in this case the null-termination is guaranteed.
> Because the max interface name length in linux is 15 and I am allocating 16 byte(IF_NAMESIZE)
> for my hip_netdev_whitelist_entry struct. And in strncpy I always write IF_NAMESIZE many bytes,
> so even in the case our system has a maximum interface name of 15, I would write at least one byte
> more and terminate the string in this manner, because strncpy would fill up the buffer with nulls.

So you are essentially saying that if HIPL gets ported to something else
than Linux, this will possibly introduce a subtle and hard to find bug? :)

Diego

Revision history for this message
Diego Biurrun (diego-biurrun) wrote : Posted in a previous version of this proposal

On Tue, Sep 13, 2011 at 03:41:04PM +0000, Christof Mroz wrote:
>
> > +
> > + if (!memcmp(addr, ifa->ifa_addr, sizeof(addr))) {
> > + if (strlen(ifa->ifa_name) < sizeoflabel) {
> > + strncpy(label, ifa->ifa_name, sizeoflabel);
> > + res = 0;
> > + }
> > + break;
> > + }
> > + }
>
> Stopper: addr is a pointer, so sizeof(addr) is always sizeof(void*); you
> meant sizeof(*addr).
>
> This one may have slipped through your tests because accidentally,
> sizeof(void*) = sizeof(struct sockaddr). Be sure to check your code with
> IPv6, too.

good catch!

> > + if (!hip_find_label_for_address(addr, label, sizeof(label)) &&
> > + !hip_netdev_is_in_white_list(ifa->ifa_index, label)) {
> > + HIP_DEBUG("Interface:<%s> is not whitelisted\n", label);
> > + continue;
> > + }
>
> Maybe it's just me, but you return zero both for success and failure
> depending on the function, which confused me at first. Probably no big
> deal since these functions are not public, though.

You can find this all over HIPL, annoying as heck if you ask me :)

Somebody should open a bug about this and add it to the eternal todo
list... :)

Diego

Revision history for this message
Diego Biurrun (diego-biurrun) wrote : Posted in a previous version of this proposal

On Tue, Sep 13, 2011 at 06:34:23PM +0000, Christof Mroz wrote:
> On Tue, 13 Sep 2011 19:43:28 +0200, Christian Röller
> <email address hidden> wrote:
>
> >> You replaced `white list' with `whitelist' in comments, so you should
> >> change it in identifiers as well: `white_list' -> `whitelist'.
> >
> > Again a case of adoption, the actual author use this syntax, so I adopt
> > it.
> > This change was more the grammar owed, which should be adhered to in
> > comments more than for variable names. ;-) But I can change it of
> > course lets see what the others think about it...
>
> Changing the comments was off-topic to begin with, so I'd be for
> finishing it (unless someone objects)

I'm for finishing it right away on trunk, outside the scope of this
branch :)

Diego

Revision history for this message
Diego Biurrun (diego-biurrun) wrote : Posted in a previous version of this proposal
Download full text (6.3 KiB)

 review needs-fixing

On Tue, Sep 13, 2011 at 12:20:34PM +0000, Christian Röller wrote:
>
> === modified file 'Makefile.am'
> --- Makefile.am 2011-08-10 15:03:07 +0000
> +++ Makefile.am 2011-09-13 12:20:25 +0000
> @@ -71,11 +71,15 @@
> TESTS = test/check_firewall \
> test/check_lib_core \
> test/check_lib_tool \
> - test/check_modules_midauth
> + test/check_modules_midauth \
> + test/check_lib_tool \
> + test/check_hipd
> check_PROGRAMS = test/check_firewall \
> test/check_lib_core \
> test/check_lib_tool \
> - test/check_modules_midauth
> + test/check_modules_midauth \
> + test/check_lib_tool \
> + test/check_hipd

duplicate entries

alphabetical order

> @@ -207,6 +211,10 @@
>
> +test_check_hipd_SOURCES = test/check_hipd.c \
> + test/hipd/netdev.c \
> + modules/midauth/hipd/midauth.c \
> + $(hipd_hipd_sources)

Please align the '\' vertically, same as in the rest of the file.

> test_check_firewall_SOURCES = test/check_firewall.c \
> test/mocks.c \

Like here for example :)

> --- hipd/netdev.c 2011-08-15 14:11:56 +0000
> +++ hipd/netdev.c 2011-09-13 12:20:25 +0000
> @@ -90,54 +90,68 @@
>
> -static int hip_netdev_white_list[HIP_NETDEV_MAX_WHITE_LIST];
> -static int hip_netdev_white_list_count = 0;
> +struct hip_netdev_whitelist_entry {
> + unsigned int if_index;
> + char if_label[IF_NAMESIZE];
> +};
> +static struct hip_netdev_whitelist_entry hip_netdev_white_list[HIP_NETDEV_MAX_WHITE_LIST];
> +static unsigned int hip_netdev_white_list_count = 0;
>
> -static void hip_netdev_white_list_add_index(int if_index)
> +static void hip_netdev_white_list_add_index_and_name(const unsigned int if_index,
> + const char *const device_name)

These unnecessary double prefixes (hip_ and netdev_) for symbols not
visible outside of this file are annoying.

In a perfect world, you would do a quick search and replace on trunk and
merge that back into your branch, but I don't want to pile too much
extra work on you. However, if you have a minute and the motivation..

Maybe you could drop them for the new code, but feel free to ignore me.

> -static int hip_netdev_is_in_white_list(int if_index)
> +static int hip_netdev_is_in_white_list(const unsigned int if_index,
> + const char *const device_name)

Oh look, this file only had a hip_ prefix - yay for consistency in HIPL,
even in the same file :)

> @@ -1120,6 +1133,44 @@
>
> /**
> + * Gives you the interface label for a given IPv4 or IPv6 address.
> + *
> + * @param addr Address for which you want to know the label
> + * @param label Pointer where the function stores the label.
> + * @param sizeoflabel Size of the passed label parameter, should be chosen big enough
> + * to be able to store...

Read more...

review: Needs Fixing
Revision history for this message
Christian Röller (christian-roeller) wrote : Posted in a previous version of this proposal

> On Tue, Sep 13, 2011 at 05:43:28PM +0000, Christian Röller wrote:
> > > Most of the following are just suggestions, though there's one stopper.
> > >
> > > > -static void hip_netdev_white_list_add_index(int if_index)
> > > > +static void hip_netdev_white_list_add_index_and_name(const unsigned int
> > > if_index,
> > > > + const char *const
> > > device_name)
> > > > {
> > > > if (hip_netdev_white_list_count < HIP_NETDEV_MAX_WHITE_LIST) {
> > > > - hip_netdev_white_list[hip_netdev_white_list_count++] =
> if_index;
> > > > + hip_netdev_white_list[hip_netdev_white_list_count].if_index =
> > > if_index;
> > > > +
> > > strncpy(hip_netdev_white_list[hip_netdev_white_list_count].if_label,
> > > > + device_name,
> sizeof(hip_netdev_white_list[0].if_label));
> > > > + hip_netdev_white_list_count++;
> > >
> > > Sorry to bring up this issue again :)
> > >
> > > I suspect you already know that the strncpy() may leave you with an
> > > unterminated if_label here, and you're betting on a sensible length of
> > > device_name. See e.g. [1] for an explanation.
> > > It's always a good idea to add an assert() when gambling, for the sole
> > > purpose of documentation if anything. But better still, I'd terminate
> > > the string explicitly.
> > >
> > > If I'm mistaken here, please comment the code (or the device_name
> > > parameter) to clarify. Audit all the other instances of strncpy() you
> > > touched, too.
> >
> > Actually you are right, but in this case the null-termination is guaranteed.
> > Because the max interface name length in linux is 15 and I am allocating 16
> byte(IF_NAMESIZE)
> > for my hip_netdev_whitelist_entry struct. And in strncpy I always write
> IF_NAMESIZE many bytes,
> > so even in the case our system has a maximum interface name of 15, I would
> write at least one byte
> > more and terminate the string in this manner, because strncpy would fill up
> the buffer with nulls.
>
> So you are essentially saying that if HIPL gets ported to something else
> than Linux, this will possibly introduce a subtle and hard to find bug? :)
>
> Diego

I had to limit the buffer length somehow, so I choose an OS-specific characteristic.
Is there a better way?

But isn't the whole whitelisting approach very os-specific(in this case linux)? I mean we base the whole whitelisting on OS-specific characteristics like interface-indeces and interface-label-names.
So maybe the whole whitelisting approach is a bug in this manner!? :)

But to be honest, I have no other idea than to treat the whitelisting separately for every OS. You?

Revision history for this message
Christian Röller (christian-roeller) wrote : Posted in a previous version of this proposal

I have submitted the code a cosmetic treatment and tried to implement all your improvement suggestions. Maybe you can have another look when you find the time...thanks

Revision history for this message
Christof Mroz (christof-mroz) wrote :

Almost there:

> + assert(strlen(device_name) < sizeof(whitelist[0].if_label));
> + if (whitelist_count < HIP_NETDEV_MAX_WHITE_LIST) {
> + whitelist[whitelist_count].if_index = if_index;
> + strncpy(whitelist[whitelist_count].if_label,
> + device_name, sizeof(whitelist[0].if_label));
> + whitelist_count++;

There's a HIP_ASSERT() macro that takes care of logging violations, and it's
correctly disabled in non-debug builds.

> - /* We should NEVER run out of white list slots!!! */
> - HIP_DIE("Error: ran out of space for white listed interfaces!\n");
> + /* We should NEVER run out of whitelist slots!!! */
> + HIP_DIE("Error: ran out of space for whitelisted interfaces!\n");

I know you didn't introduce the comment, but it's stupid nevertheless.

> - strncpy(ifr.ifr_name, device_name, IF_NAMESIZE);
> + strncpy(ifr.ifr_name, device_name, sizeof(ifr.ifr_name));

Would a HIP_ASSERT be appropriate here as well?

> * @return interface index if the network address is bound to one, zero if
> - * no interface index was found.
> + * no interface index was found.
> */

Unrelated: is zero a valid index, according to netlink? eth0 is, after all.
Changing the return value on failure to a negative number won't hurt
in any case.

> +START_TEST(test_hip_netdev_find_label_for_address_parameters)
> +{
> + struct ifaddrs *myaddrs, *ifa = NULL;
> + char label[IF_NAMESIZE];
> +
> + /* The passed label parameter for the function hip_find_label_for_address
> + * must be at least 1 greater than the found label in the function. So
> + * a size of 1 would be for sure too short to store at least the shortest
> + * label of only 1 character.
> + */
> + char label_too_short[1];
> +
> + getifaddrs(&myaddrs);

You should warn that this test was skipped if getifaddrs() doesn't return anything.
Using mock functions would be more correct, but in this case it's probably not
worth the effort.

review: Needs Fixing
Revision history for this message
Diego Biurrun (diego-biurrun) wrote :

 review needs-fixing

On Wed, Sep 14, 2011 at 12:50:08PM +0000, Christian Röller wrote:
> Christian Röller has proposed merging lp:~christian-roeller/hipl/whitelisting into lp:hipl.

The size of this merge proposal has grown from 19k to 30k overnight.
This is a problem. Note that review time grows more than linearly
with change size. Note further that most of the reviewers work on
HIPL in their free time.

You have added many completely unrelated changes to this merge
proposal. I know your intentions are good, but unfortunately
the result is not.

This merge proposal is about whitelisting. Changes not related to
whitelisting do *not* belong here. They should either go in a
separate merge proposal or be committed directly to trunk.

I bet you have only a single branch and do all your work in there, right?
This is a very common workstyle for people coming from centralized
revision control systems, but not a good way to work with Bazaar.
Start unleashing its power and branch merrily. I have had days where
I created and threw away a dozen or more branches.

Now please go ahead and create a separate branch for your whitespace
changes. You will be surprised how quickly that will get approved
and how much quicker your whitelisting branch will get approval :)

Happy branching, Diego

review: Needs Fixing
Revision history for this message
Stefan Götz (stefan.goetz-deactivatedaccount) wrote :

I second Christof's comments; please address them. As for Diego's comments, I agree wholeheartedly but I'd let you get away with a 'keep unrelated changes out of your next branch/merge proposal'. No further comments from my side.

review: Needs Fixing
Revision history for this message
Diego Biurrun (diego-biurrun) wrote :

On Wed, Sep 14, 2011 at 07:43:47PM +0000, Stefan Götz wrote:
> Review: Needs Fixing
>
> As for Diego's comments, I agree wholeheartedly but I'd let you get
> away with a 'keep unrelated changes out of your next branch/merge
> proposal'.

All of this really should not be that hard with the help of the rebase,
merge and replay bzr commands or even with diff and patch. The more
practice one gets using these tools, the better :)

In all the projects I worked, unrelated changes in a patch were an
automatic reject, no further questions asked...

Diego

Revision history for this message
Christian Röller (christian-roeller) wrote :

> On Wed, Sep 14, 2011 at 07:43:47PM +0000, Stefan Götz wrote:
> > Review: Needs Fixing
> >
> > As for Diego's comments, I agree wholeheartedly but I'd let you get
> > away with a 'keep unrelated changes out of your next branch/merge
> > proposal'.
>
> All of this really should not be that hard with the help of the rebase,
> merge and replay bzr commands or even with diff and patch. The more
> practice one gets using these tools, the better :)
>
> In all the projects I worked, unrelated changes in a patch were an
> automatic reject, no further questions asked...
>
> Diego

I totally agree to that Diego, it was no good idea to mix up here different things.
I just did it because I have changed all comments for the whitelisting relevant functions
and just wanted to take care of consistency in the whole file.

You are right a little bit more practice with bazaar couldn't be bad :),
because this is the first time I really use it. But is it really worthwhile this time
to create an own branch for it? I mean I would just change a few comment alignment issues in one file. But as I said in the beginning I agree to that in principle.
So if it is wished, I will try to do it. Even though this could take a few days, because I have to
do first a lot of other things this week.

Regards,
Christian

Revision history for this message
Diego Biurrun (diego-biurrun) wrote :

On Thu, Sep 15, 2011 at 01:43:18PM +0000, Christian Röller wrote:
> > On Wed, Sep 14, 2011 at 07:43:47PM +0000, Stefan Götz wrote:
> > > Review: Needs Fixing
> > >
> > > As for Diego's comments, I agree wholeheartedly but I'd let you get
> > > away with a 'keep unrelated changes out of your next branch/merge
> > > proposal'.
> >
> > All of this really should not be that hard with the help of the rebase,
> > merge and replay bzr commands or even with diff and patch. The more
> > practice one gets using these tools, the better :)
> >
> > In all the projects I worked, unrelated changes in a patch were an
> > automatic reject, no further questions asked...
>
> I totally agree to that Diego, it was no good idea to mix up here different things.
> I just did it because I have changed all comments for the whitelisting relevant functions
> and just wanted to take care of consistency in the whole file.
>
> You are right a little bit more practice with bazaar couldn't be bad :),
> because this is the first time I really use it. But is it really worthwhile this time
> to create an own branch for it?

Yes.

> I mean I would just change a few comment alignment issues in one file.
> But as I said in the beginning I agree to that in principle.
> So if it is wished, I will try to do it. Even though this could take a
> few days, because I have to do first a lot of other things this week.

It really should not take you long. You can poke me on IRC if you have
trouble.

Diego

Revision history for this message
René Hummen (rene-hummen) wrote :

On 15.09.2011, at 15:43, Christian Röller wrote:
>> On Wed, Sep 14, 2011 at 07:43:47PM +0000, Stefan Götz wrote:
>>> Review: Needs Fixing
>>>
>>> As for Diego's comments, I agree wholeheartedly but I'd let you get
>>> away with a 'keep unrelated changes out of your next branch/merge
>>> proposal'.
>>
>> All of this really should not be that hard with the help of the rebase,
>> merge and replay bzr commands or even with diff and patch. The more
>> practice one gets using these tools, the better :)
>>
>> In all the projects I worked, unrelated changes in a patch were an
>> automatic reject, no further questions asked...
>>
>> Diego
>
> I totally agree to that Diego, it was no good idea to mix up here different things.
> I just did it because I have changed all comments for the whitelisting relevant functions
> and just wanted to take care of consistency in the whole file.
>
> You are right a little bit more practice with bazaar couldn't be bad :),
> because this is the first time I really use it. But is it really worthwhile this time
> to create an own branch for it? I mean I would just change a few comment alignment issues in one file. But as I said in the beginning I agree to that in principle.
> So if it is wished, I will try to do it. Even though this could take a few days, because I have to
> do first a lot of other things this week.

Please address Christof's comments. I agree with Stefan that for this time your branch is ok, but please take care to only propose related issues.

Ciao,
René

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 20772
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/

Unmerged revisions

5999. By Christian Röller

Cosmetic issues in all files.

5998. By Christian Röller

Cosmetic issues in both files.

5997. By Christian Röller

A few cosmetic changes and correct one mistake regarding the use of sizeof.

5996. By Christian Röller

Rebase with trunk.

5995. By Christian Röller

Add Unit-Tests for the new function hip_find_label_for_address in /hipd/netdev.c

5994. By Christian Röller

Increase the n by 1 in strncpy regarding the writing of the interfacelabel to guarantee null-termination.

5993. By Christian Röller

cosmetic: alignments in function description hip_find_label_for_address

5992. By Christian Röller

cosmetic: correct some typos

5991. By Christian Röller

cosmetic: typo in function description

5990. By Christian Röller

cosmetic: shorten a few things

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'Makefile.am'
2--- Makefile.am 2011-08-10 15:03:07 +0000
3+++ Makefile.am 2011-09-14 12:49:45 +0000
4@@ -68,13 +68,15 @@
5
6 ### tests ###
7 if HIP_UNITTESTS
8-TESTS = test/check_firewall \
9- test/check_lib_core \
10- test/check_lib_tool \
11- test/check_modules_midauth
12-check_PROGRAMS = test/check_firewall \
13- test/check_lib_core \
14- test/check_lib_tool \
15+TESTS = test/check_firewall \
16+ test/check_hipd \
17+ test/check_lib_core \
18+ test/check_lib_tool \
19+ test/check_modules_midauth
20+check_PROGRAMS = test/check_firewall \
21+ test/check_hipd \
22+ test/check_lib_core \
23+ test/check_lib_tool \
24 test/check_modules_midauth
25 endif
26
27@@ -207,6 +209,10 @@
28 lib_core_libhipcore_la_SOURCES += lib/core/performance.c
29 endif
30
31+test_check_hipd_SOURCES = modules/midauth/hipd/midauth.c \
32+ test/check_hipd.c \
33+ test/hipd/netdev.c \
34+ $(hipd_hipd_sources)
35
36 test_check_firewall_SOURCES = test/check_firewall.c \
37 test/mocks.c \
38@@ -240,6 +246,7 @@
39 hipd_hipd_LDADD = lib/core/libhipcore.la
40 test_auth_performance_LDADD = lib/core/libhipcore.la
41 test_check_firewall_LDADD = lib/core/libhipcore.la
42+test_check_hipd_LDADD = lib/core/libhipcore.la
43 test_check_lib_core_LDADD = lib/core/libhipcore.la
44 test_check_lib_tool_LDADD = lib/core/libhipcore.la
45 test_check_modules_midauth_LDADD = lib/core/libhipcore.la
46
47=== modified file 'hipd/input.c'
48--- hipd/input.c 2011-08-25 12:12:27 +0000
49+++ hipd/input.c 2011-09-14 12:49:45 +0000
50@@ -521,7 +521,7 @@
51 /* RVS/Relay is handled later in the code. */
52 if (hip_relay_get_status() == HIP_RELAY_OFF)
53 #endif
54- return -1;
55+ return -1;
56 }
57
58 /* Debug printing of received packet information. All received HIP
59
60=== modified file 'hipd/netdev.c'
61--- hipd/netdev.c 2011-08-15 14:11:56 +0000
62+++ hipd/netdev.c 2011-09-14 12:49:45 +0000
63@@ -53,6 +53,7 @@
64 #include <openssl/rand.h>
65 #include <sys/ioctl.h>
66 #include <linux/rtnetlink.h>
67+#include <assert.h>
68
69 #include "lib/core/builder.h"
70 #include "lib/core/common.h"
71@@ -79,7 +80,7 @@
72
73 /**
74 * We really don't expect more than a handfull of interfaces to be on
75- * our white list.
76+ * our whitelist.
77 */
78 #define HIP_NETDEV_MAX_WHITE_LIST 5
79
80@@ -90,43 +91,56 @@
81 #define FAM_STR_MAX 32
82
83 /**
84- * This is the white list. For every interface, which is in our white list,
85+ * This is the whitelist. For every interface, which is in our whitelist,
86 * this array has a fixed size, because there seems to be no need at this
87 * moment to deal with dynamic memory - which would complicate the code
88 * and cost size and performance at least equal if not more to this fixed
89 * size array.
90 * Free slots are signaled by the value -1.
91 */
92-static int hip_netdev_white_list[HIP_NETDEV_MAX_WHITE_LIST];
93-static int hip_netdev_white_list_count = 0;
94+struct whitelist_entry {
95+ unsigned int if_index;
96+ char if_label[IF_NAMESIZE];
97+};
98+static struct whitelist_entry whitelist[HIP_NETDEV_MAX_WHITE_LIST];
99+static unsigned int whitelist_count = 0;
100
101 /**
102- * Add a network interface index number to the list of white listed
103+ * Add a network interface index number plus label to the list of whitelisted
104 * network interfaces.
105 *
106- * @param if_index the network interface index to be white listed
107+ * @param if_index the network interface index to be whitelisted
108+ * @param device_name the network interface label to be whitelisted
109 */
110-static void hip_netdev_white_list_add_index(int if_index)
111+static void whitelist_add_index_and_name(const unsigned int if_index,
112+ const char *const device_name)
113 {
114- if (hip_netdev_white_list_count < HIP_NETDEV_MAX_WHITE_LIST) {
115- hip_netdev_white_list[hip_netdev_white_list_count++] = if_index;
116+ assert(strlen(device_name) < sizeof(whitelist[0].if_label));
117+ if (whitelist_count < HIP_NETDEV_MAX_WHITE_LIST) {
118+ whitelist[whitelist_count].if_index = if_index;
119+ strncpy(whitelist[whitelist_count].if_label,
120+ device_name, sizeof(whitelist[0].if_label));
121+ whitelist_count++;
122 } else {
123- /* We should NEVER run out of white list slots!!! */
124- HIP_DIE("Error: ran out of space for white listed interfaces!\n");
125+ /* We should NEVER run out of whitelist slots!!! */
126+ HIP_DIE("Error: ran out of space for whitelisted interfaces!\n");
127 }
128 }
129
130 /**
131- * Test if the given network interface index is white listed.
132+ * Test if the given network interface index plus label is whitelisted.
133 *
134- * @param if_index the index of the network interface to be tested
135- * @return 1 if the index is whitelisted or zero otherwise
136+ * @param if_index the index of the network interface to be tested
137+ * @param device_name the label of the network interface to be tested
138+ * @return 1 if the index is whitelisted or zero otherwise
139 */
140-static int hip_netdev_is_in_white_list(int if_index)
141+static int is_in_whitelist(const unsigned int if_index,
142+ const char *const device_name)
143 {
144- int i = 0;
145- for (i = 0; i < hip_netdev_white_list_count; i++) {
146- if (hip_netdev_white_list[i] == if_index) {
147+ for (unsigned int i = 0; i < whitelist_count; i++) {
148+ if (whitelist[i].if_index == if_index &&
149+ !strncmp(whitelist[i].if_label,
150+ device_name, sizeof(whitelist[0].if_label))) {
151 return 1;
152 }
153 }
154@@ -134,11 +148,11 @@
155 }
156
157 /**
158- * Add a network interface index number to the list of white listed
159+ * Add a network interface index number to the list of whitelisted
160 * network interfaces by name.
161 *
162- * @param device_name the name of the device to be white listed
163- * @return 1 on success, 0 on error
164+ * @param device_name the name of the device to be whitelisted
165+ * @return 1 on success, 0 on error
166 */
167 int hip_netdev_white_list_add(const char *const device_name)
168 {
169@@ -146,19 +160,18 @@
170 int sock = 0;
171 int ret = 0;
172
173- strncpy(ifr.ifr_name, device_name, IF_NAMESIZE);
174+ strncpy(ifr.ifr_name, device_name, sizeof(ifr.ifr_name));
175 sock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
176
177 if (ioctl(sock, SIOCGIFINDEX, &ifr) == 0) {
178 ret = 1;
179- hip_netdev_white_list_add_index(ifr.ifr_ifindex);
180- HIP_DEBUG("Adding device <%s> to white list with index <%i>.\n",
181+ whitelist_add_index_and_name(ifr.ifr_ifindex, device_name);
182+ HIP_DEBUG("Adding device <%s> to whitelist with index <%i>.\n",
183 device_name,
184 ifr.ifr_ifindex);
185 } else {
186 ret = 0;
187 }
188-
189 if (sock) {
190 close(sock);
191 }
192@@ -169,7 +182,7 @@
193 * hash function for the addresses hash table
194 *
195 * @param ptr a pointer to a netdev_address structure
196- * @return the calculated hash to index the parameter
197+ * @return the calculated hash to index the parameter
198 */
199 static unsigned long hip_netdev_hash(const void *ptr)
200 {
201@@ -195,7 +208,7 @@
202 *
203 * @param ptr1 a pointer to a netdev_address structure
204 * @param ptr2 a pointer to a netdev_address structure
205- * @return 0 if the given pointers match or 1 otherwise
206+ * @return 0 if the given pointers match or 1 otherwise
207 */
208 static int hip_netdev_match(const void *ptr1, const void *ptr2)
209 {
210@@ -300,7 +313,7 @@
211 * parties should have a matching IP address family.
212 *
213 * @param addr addr the address to be tested (IPv4 address in IPv6 mapped format) for family
214- * @return one if the address is recorded in the cache and zero otherwise
215+ * @return one if the address is recorded in the cache and zero otherwise
216 */
217 static int hip_exists_address_family_in_list(const struct in6_addr *addr)
218 {
219@@ -323,10 +336,10 @@
220 /**
221 * Test if the given address with the given network interface index exists in the cache
222 *
223- * @param addr A sockaddr structure containing the address to be checked. An IPv6 socket
224- * address structure can also contain an IPv4 address in IPv6-mapped format.
225+ * @param addr A sockaddr structure containing the address to be checked. An IPv6 socket
226+ * address structure can also contain an IPv4 address in IPv6-mapped format.
227 * @param ifindex the network interface index
228- * @return one if the index exists in the cache or zero otherwise
229+ * @return one if the index exists in the cache or zero otherwise
230 */
231 int hip_exists_address_in_list(struct sockaddr *addr, int ifindex)
232 {
233@@ -393,9 +406,9 @@
234 * advertisements (UPDATE control message with a LOCATOR parameter) to
235 * peers.
236 *
237- * @param addr a pointer to a socket address structure.
238+ * @param addr a pointer to a socket address structure.
239 * @param ifindex network device interface index.
240- * @param flags flags
241+ * @param flags flags
242 */
243 void hip_add_address_to_list(struct sockaddr *addr, int ifindex, int flags)
244 {
245@@ -442,8 +455,8 @@
246 /**
247 * Delete an address from address cache of localhost addresses
248 *
249- * @param addr A sockaddr structure containing the address to be deleted.
250- * IPv4 addresses can be in IPv6-mapped format.
251+ * @param addr A sockaddr structure containing the address to be deleted.
252+ * IPv4 addresses can be in IPv6-mapped format.
253 * @param ifindex the network interface on which the address is attached to
254 */
255 static void hip_delete_address_from_list(struct sockaddr *addr, int ifindex)
256@@ -522,10 +535,10 @@
257 /**
258 * Get the interface index of a socket address.
259 *
260- * @param addr a pointer to a socket address whose interface index is to be
261- * searched.
262+ * @param addr a pointer to a socket address whose interface index is to be
263+ * searched.
264 * @return interface index if the network address is bound to one, zero if
265- * no interface index was found.
266+ * no interface index was found.
267 */
268 static int hip_netdev_find_if(struct sockaddr *addr)
269 {
270@@ -587,12 +600,12 @@
271 * a function that gets the ifindex of the network device which has the address
272 * @c addr.
273 *
274- * @param addr a pointer to an IPv6 address whose interface index is to be
275- * searched.
276- * @return interface index if the network address is bound to one, zero if
277- * no interface index was found and negative in error case.
278- * @todo The caller of this should be generalized to both IPv4 and IPv6
279- * so that this function can be removed (tkoponen).
280+ * @param addr a pointer to an IPv6 address whose interface index is to be
281+ * searched.
282+ * @return interface index if the network address is bound to one, zero if
283+ * no interface index was found and negative in error case.
284+ * @todo The caller of this should be generalized to both IPv4 and IPv6
285+ * so that this function can be removed (tkoponen).
286 */
287 int hip_devaddr2ifindex(struct in6_addr *addr)
288 {
289@@ -606,9 +619,9 @@
290 * Initialize the address cache of localhost addresses
291 *
292 * @return zero on success and non-zero on error
293- * @todo This creates a new NETLINK socket (via getifaddrs), so this has to be
294- * run before the global NETLINK socket is opened. We did not have the time
295- * and energy to import all of the necessary functionality from iproute2.
296+ * @todo This creates a new NETLINK socket (via getifaddrs), so this has to be
297+ * run before the global NETLINK socket is opened. We did not have the time
298+ * and energy to import all of the necessary functionality from iproute2.
299 */
300 int hip_netdev_init_addresses(void)
301 {
302@@ -632,7 +645,7 @@
303 HIP_IFEL(!(if_index = if_nametoindex(g_iface->ifa_name)),
304 -1, "if_nametoindex failed\n");
305 /* Check if our interface is in the whitelist */
306- if ((hip_netdev_white_list_count > 0) && (!hip_netdev_is_in_white_list(if_index))) {
307+ if ((!is_in_whitelist(if_index, g_iface->ifa_name))) {
308 continue;
309 }
310
311@@ -650,12 +663,12 @@
312 * Try to map a given HIT or an LSI to a routable IP address using local host association
313 * data base, hosts files or DNS (in the presented order).
314 *
315- * @param hit a HIT to map to a LSI
316- * @param lsi an LSI to map to an IP address
317+ * @param hit a HIT to map to a LSI
318+ * @param lsi an LSI to map to an IP address
319 * @param addr output argument to which this function writes the address if found
320- * @return zero on success and non-zero on error
321- * @note Either HIT or LSI must be given. If both are given, the HIT is preferred.
322- * @todo move this to some other file (this file contains local IP address management, not remote)
323+ * @return zero on success and non-zero on error
324+ * @note Either HIT or LSI must be given. If both are given, the HIT is preferred.
325+ * @todo move this to some other file (this file contains local IP address management, not remote)
326 */
327 int hip_map_id_to_addr(const hip_hit_t *hit, const hip_lsi_t *lsi,
328 struct in6_addr *addr)
329@@ -726,21 +739,21 @@
330 * arguments. This function also supports HIP-based loopback
331 * connectivity and hiccups (data packet) extensions.
332 *
333- * @param src_hit_in The source HIT for the I1. Alternatively, NULL if default
334- * HIT is suitable
335- * @param dst_hit_in The destination HIT. This HIT cannot be a "pseudo HIT" as
336- * used by the opportunistic mode. Use hip_send_i1() function
337- * instead with opportunistic mode.
338- * @param src_lsi_in Optional source LSI corresponding to the source HIT
339- * @param dst_lsi_in Optional destination LSI corresponding to the destination HIT
340+ * @param src_hit_in The source HIT for the I1. Alternatively, NULL if default
341+ * HIT is suitable
342+ * @param dst_hit_in The destination HIT. This HIT cannot be a "pseudo HIT" as
343+ * used by the opportunistic mode. Use hip_send_i1() function
344+ * instead with opportunistic mode.
345+ * @param src_lsi_in Optional source LSI corresponding to the source HIT
346+ * @param dst_lsi_in Optional destination LSI corresponding to the destination HIT
347 * @param src_addr_in Source address for the I1 (IPv4 address in IPv6 mapped format)
348 * @param dst_addr_in Destination address for the I1 (IPv4 address in IPv6 mapped format)
349- * @return zero on success and non-zero on error
350- * @note HITs can be NULL if the LSIs are non-NULL (and vice versa).
351- * @note The locators (addresses) can be NULL. This function will
352- * try to map the HITs or LSIs to IP addresses. IPv4 broadcast
353- * will be used as a last resort.
354- * @todo move this function to some other file
355+ * @return zero on success and non-zero on error
356+ * @note HITs can be NULL if the LSIs are non-NULL (and vice versa).
357+ * @note The locators (addresses) can be NULL. This function will
358+ * try to map the HITs or LSIs to IP addresses. IPv4 broadcast
359+ * will be used as a last resort.
360+ * @todo move this function to some other file
361 */
362 static int hip_netdev_trigger_bex(const hip_hit_t *src_hit_in,
363 const hip_hit_t *dst_hit_in,
364@@ -966,8 +979,8 @@
365 * Handle an "acquire" message from the kernel by triggering a base exchange.
366 *
367 * @param msg a netlink "acquire" message
368- * @return zero on success and non-zero on error
369- * @todo move this to some other file
370+ * @return zero on success and non-zero on error
371+ * @todo move this to some other file
372 */
373 static int hip_netdev_handle_acquire(struct nlmsghdr *msg)
374 {
375@@ -1012,8 +1025,8 @@
376 *
377 * @param msg the HIP user message containing HITs, LSIs and addresses as
378 * parameters
379- * @return zero on success and non-zero on error
380- * @todo move this to some other file
381+ * @return zero on success and non-zero on error
382+ * @todo move this to some other file
383 */
384 int hip_netdev_trigger_bex_msg(const struct hip_common *msg)
385 {
386@@ -1120,6 +1133,44 @@
387 }
388
389 /**
390+ * Returns the interface label for a given IPv4 or IPv6 address.
391+ *
392+ * @param addr Address for which you want to know the label
393+ * @param label Pointer where the function stores the label.
394+ * For the label should be at least 16 bytes allocated.
395+ * @param label_size Size of the passed label parameter, should be chosen big enough
396+ * to be able to store every possible interface name plus NULL-termination.
397+ * @return Zero on success, one on error and write the label
398+ * in param label if the given address exists in the system.
399+ * Label will be NULL-terminated for sure, iff param label
400+ * is chosen big enough(at least 16 bytes).
401+ */
402+int hip_netdev_find_label_for_address(const struct sockaddr *const addr,
403+ char *const label, const unsigned int label_size)
404+{
405+ int res = 1;
406+ struct ifaddrs *myaddrs, *ifa = NULL;
407+
408+ getifaddrs(&myaddrs);
409+ for (ifa = myaddrs; ifa != NULL; ifa = ifa->ifa_next) {
410+ if (ifa->ifa_addr->sa_family != AF_INET &&
411+ ifa->ifa_addr->sa_family != AF_INET6) {
412+ continue;
413+ }
414+
415+ if (!memcmp(addr, ifa->ifa_addr, sizeof(*addr))) {
416+ if (strlen(ifa->ifa_name) < label_size) {
417+ strncpy(label, ifa->ifa_name, label_size);
418+ res = 0;
419+ }
420+ break;
421+ }
422+ }
423+ freeifaddrs(myaddrs);
424+ return res;
425+}
426+
427+/**
428 * Netlink event handler. Handles IPsec acquire messages (triggering
429 * of base exchange) and updates the cache of local addresses when
430 * address changes occur.
431@@ -1127,7 +1178,7 @@
432 * @param msg a netlink message
433 * @param len the length of the netlink message in bytes
434 * @param arg argument to pass (needed because of the callaback nature)
435- * @return zero on success and non-zero on error
436+ * @return zero on success and non-zero on error
437 */
438 int hip_netdev_event(struct nlmsghdr *msg, int len, UNUSED void *arg)
439 {
440@@ -1165,11 +1216,6 @@
441 rta = IFA_RTA(ifa);
442 l = msg->nlmsg_len - NLMSG_LENGTH(sizeof(*ifa));
443
444- /* Check if our interface is in the whitelist */
445- if ((hip_netdev_white_list_count > 0) &&
446- (!hip_netdev_is_in_white_list(ifindex))) {
447- continue;
448- }
449
450 if ((ifa->ifa_family != AF_INET) &&
451 (ifa->ifa_family != AF_INET6)) {
452@@ -1211,6 +1257,17 @@
453 HIP_DEBUG("Unknown addr family in addr\n");
454 }
455
456+ /* find interface label for address and check if it is whitelisted or not */
457+ if (is_add) {
458+ char label[IF_NAMESIZE];
459+ if (!hip_netdev_find_label_for_address(addr, label, sizeof(label)) &&
460+ !is_in_whitelist(ifa->ifa_index, label)) {
461+ HIP_DEBUG("Interface:<%s> is not whitelisted\n", label);
462+ continue;
463+ }
464+ }
465+
466+
467 /* Trying to add an existing address or deleting a non-existing
468 * address */
469 exists = hip_exists_address_in_list(addr, ifa->ifa_index);
470@@ -1303,7 +1360,7 @@
471 * @param local_hit The HIT to be removed.
472 * @return Zero on success, non-zero on failure.
473 *
474- * @see hip_manage_iface_local_hit()
475+ * @see hip_manage_iface_local_hit()
476 */
477 static int hip_remove_iface_local_hit(const hip_hit_t *const local_hit)
478 {
479@@ -1340,7 +1397,7 @@
480 * signature.
481 * @return Zero on success, non-zero on failure.
482 *
483- * @see hip_remove_iface_all_local_hits()
484+ * @see hip_remove_iface_all_local_hits()
485 */
486 static int hip_remove_iface_hit_by_host_id(struct local_host_id *entry,
487 UNUSED void *opaque)
488@@ -1360,7 +1417,7 @@
489 * Add a route to a local HIT
490 *
491 * @param local_hit the local HIT for which a route should be added
492- * @return zero on success and non-zero on error
493+ * @return zero on success and non-zero on error
494 */
495 int hip_add_iface_local_route(const hip_hit_t *local_hit)
496 {
497@@ -1387,7 +1444,7 @@
498 * will be in IPv6-mapped format.
499 * @param dst The destination address. IPv4 addresses must be in
500 * in IPv6-mapped format.
501- * @return zero on success and non-zero on failure
502+ * @return zero on success and non-zero on failure
503 */
504 int hip_select_source_address(struct in6_addr *src, const struct in6_addr *dst)
505 {
506
507=== modified file 'hipd/netdev.h'
508--- hipd/netdev.h 2011-05-18 15:12:07 +0000
509+++ hipd/netdev.h 2011-09-14 12:49:45 +0000
510@@ -56,4 +56,7 @@
511 int hip_map_id_to_addr(const hip_hit_t *hit, const hip_lsi_t *lsi,
512 struct in6_addr *addr);
513
514+int hip_netdev_find_label_for_address(const struct sockaddr *const addr,
515+ char *const label, const unsigned int label_size);
516+
517 #endif /* HIP_HIPD_NETDEV_H */
518
519=== added file 'test/check_hipd.c'
520--- test/check_hipd.c 1970-01-01 00:00:00 +0000
521+++ test/check_hipd.c 2011-09-14 12:49:45 +0000
522@@ -0,0 +1,41 @@
523+/*
524+ * Copyright (c) 2011 Aalto University and RWTH Aachen University.
525+ *
526+ * Permission is hereby granted, free of charge, to any person
527+ * obtaining a copy of this software and associated documentation
528+ * files (the "Software"), to deal in the Software without
529+ * restriction, including without limitation the rights to use,
530+ * copy, modify, merge, publish, distribute, sublicense, and/or sell
531+ * copies of the Software, and to permit persons to whom the
532+ * Software is furnished to do so, subject to the following
533+ * conditions:
534+ *
535+ * The above copyright notice and this permission notice shall be
536+ * included in all copies or substantial portions of the Software.
537+ *
538+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
539+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
540+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
541+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
542+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
543+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
544+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
545+ * OTHER DEALINGS IN THE SOFTWARE.
546+ */
547+
548+#include <check.h>
549+#include <stdlib.h>
550+
551+#include "test/hipd/test_suites.h"
552+
553+int main(void)
554+{
555+ int number_failed;
556+ SRunner *sr = srunner_create(NULL);
557+ srunner_add_suite(sr, hipd_netdev());
558+
559+ srunner_run_all(sr, CK_NORMAL);
560+ number_failed = srunner_ntests_failed(sr);
561+ srunner_free(sr);
562+ return (number_failed == 0) ? EXIT_SUCCESS : EXIT_FAILURE;
563+}
564
565=== added directory 'test/hipd'
566=== added file 'test/hipd/netdev.c'
567--- test/hipd/netdev.c 1970-01-01 00:00:00 +0000
568+++ test/hipd/netdev.c 2011-09-14 12:49:45 +0000
569@@ -0,0 +1,92 @@
570+/*
571+ * Copyright (c) 2011 Aalto University and RWTH Aachen University.
572+ *
573+ * Permission is hereby granted, free of charge, to any person
574+ * obtaining a copy of this software and associated documentation
575+ * files (the "Software"), to deal in the Software without
576+ * restriction, including without limitation the rights to use,
577+ * copy, modify, merge, publish, distribute, sublicense, and/or sell
578+ * copies of the Software, and to permit persons to whom the
579+ * Software is furnished to do so, subject to the following
580+ * conditions:
581+ *
582+ * The above copyright notice and this permission notice shall be
583+ * included in all copies or substantial portions of the Software.
584+ *
585+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
586+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
587+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
588+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
589+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
590+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
591+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
592+ * OTHER DEALINGS IN THE SOFTWARE.
593+ */
594+
595+#include <check.h>
596+#include <stdlib.h>
597+#include <ifaddrs.h>
598+#include <net/if.h>
599+
600+#include "hipd/netdev.h"
601+#include "lib/core/debug.h"
602+#include "lib/core/prefix.h"
603+#include "test_suites.h"
604+
605+
606+
607+START_TEST(test_hip_netdev_find_label_for_address_parameters)
608+{
609+ struct ifaddrs *myaddrs, *ifa = NULL;
610+ char label[IF_NAMESIZE];
611+
612+ /* The passed label parameter for the function hip_find_label_for_address
613+ * must be at least 1 greater than the found label in the function. So
614+ * a size of 1 would be for sure too short to store at least the shortest
615+ * label of only 1 character.
616+ */
617+ char label_too_short[1];
618+
619+ getifaddrs(&myaddrs);
620+ for (ifa = myaddrs; ifa != NULL; ifa = ifa->ifa_next) {
621+ if (ifa->ifa_addr == NULL ||
622+ (ifa->ifa_addr->sa_family != AF_INET &&
623+ ifa->ifa_addr->sa_family != AF_INET6)) {
624+ continue;
625+ }
626+ HIP_DEBUG("Size of chosen label: %d\n", sizeof(label));
627+ if (ifa->ifa_addr->sa_family == AF_INET) {
628+ HIP_DEBUG_INADDR("Try to find label for addr...",
629+ hip_cast_sa_addr((struct sockaddr *) (ifa->ifa_addr)));
630+ } else {
631+ HIP_DEBUG_IN6ADDR("Try to find label for addr...",
632+ hip_cast_sa_addr((struct sockaddr *) (ifa->ifa_addr)));
633+ }
634+
635+ fail_unless(hip_netdev_find_label_for_address(ifa->ifa_addr, label, sizeof(label)) == 0,
636+ "Could not find label although address must be known.");
637+
638+ HIP_DEBUG("Found: %s\n", label);
639+
640+ HIP_DEBUG("Size of chosen label: %d\n", sizeof(label_too_short));
641+ HIP_DEBUG("Try to store in the too short chosen label parameter, return has to be 1\n");
642+
643+ fail_unless(hip_netdev_find_label_for_address(ifa->ifa_addr, label_too_short, sizeof(label_too_short)) == 1,
644+ "Not enough memory allocated for the label parameter.");
645+
646+ HIP_DEBUG("Return of function: %d \n",
647+ hip_netdev_find_label_for_address(ifa->ifa_addr, label_too_short, sizeof(label_too_short)));
648+ }
649+}
650+END_TEST
651+
652+Suite *hipd_netdev(void)
653+{
654+ Suite *s = suite_create("hipd/netdev");
655+
656+ TCase *tc_netdev = tcase_create("netdev");
657+ tcase_add_test(tc_netdev, test_hip_netdev_find_label_for_address_parameters);
658+ suite_add_tcase(s, tc_netdev);
659+
660+ return s;
661+}
662
663=== added file 'test/hipd/test_suites.h'
664--- test/hipd/test_suites.h 1970-01-01 00:00:00 +0000
665+++ test/hipd/test_suites.h 2011-09-14 12:49:45 +0000
666@@ -0,0 +1,33 @@
667+/*
668+ * Copyright (c) 2011 Aalto University and RWTH Aachen University.
669+ *
670+ * Permission is hereby granted, free of charge, to any person
671+ * obtaining a copy of this software and associated documentation
672+ * files (the "Software"), to deal in the Software without
673+ * restriction, including without limitation the rights to use,
674+ * copy, modify, merge, publish, distribute, sublicense, and/or sell
675+ * copies of the Software, and to permit persons to whom the
676+ * Software is furnished to do so, subject to the following
677+ * conditions:
678+ *
679+ * The above copyright notice and this permission notice shall be
680+ * included in all copies or substantial portions of the Software.
681+ *
682+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
683+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
684+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
685+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
686+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
687+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
688+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
689+ * OTHER DEALINGS IN THE SOFTWARE.
690+ */
691+
692+#ifndef HIP_TEST_HIPD_TEST_SUITES_H
693+#define HIP_TEST_HIPD_TEST_SUITES_H
694+
695+#include <check.h>
696+
697+Suite *hipd_netdev(void);
698+
699+#endif /* HIP_TEST_HIPD_TEST_SUITES_H */
700
701=== modified file 'test/lib/core/hostid.c'
702--- test/lib/core/hostid.c 2011-09-05 08:46:53 +0000
703+++ test/lib/core/hostid.c 2011-09-14 12:49:45 +0000
704@@ -65,7 +65,7 @@
705 START_TEST(test_serialize_deserialize_rsa_keys)
706 {
707 unsigned int i, keyrr_len = 0;
708- int bits[3] = {1024, 2048, 3072};
709+ int bits[3] = { 1024, 2048, 3072 };
710 RSA *key = NULL, *key_deserialized = NULL;
711 EVP_PKEY *key_a = NULL, *key_b = NULL;
712 unsigned char *keyrr;

Subscribers

People subscribed via source and target branches