From: Steve Grubb <sgrubb@redhat.com>
To: Stephan Mueller <smueller@atsec.com>
Cc: linux-audit@redhat.com
Subject: Re: Bad bug in remote logging
Date: Tue, 12 Apr 2011 09:09:37 -0400 [thread overview]
Message-ID: <201104120909.37444.sgrubb@redhat.com> (raw)
In-Reply-To: <201104120923.08354.smueller@atsec.com>
On Tuesday, April 12, 2011 03:23:08 AM Stephan Mueller wrote:
> Am Dienstag, 12. April 2011, um 05:18:44 schrieb Linda Knippers:
>
> Hi Linda,
>
> > Steve Grubb wrote:
> > > Hello,
> > >
> > > There was a bug reported to day that I think merits an email and/or
> > > discussion.
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=695419
> > > =================================
> > > audisp-remote does
> > >
> > >> memset (&address, 0, sizeof(address));
> > >> address.sin_family = htons(AF_INET);
> > >> address.sin_port = htons(config.local_port);
> > >> address.sin_addr.s_addr = htonl(INADDR_ANY);
> > >
> > > which shows in strace as
> > >
> > >> bind(3, {sa_family=0x200 /* AF_??? */,
> > >> sa_data="\0<\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) =
>
> Bind does not do anything with the family - it just calls the bind callback
> function set for the protocol by the socket syscall. What is the socket
> syscall saying here?
The socket call is correct.
socket (AF_INET, SOCK_STREAM, 0);
> Note that the socket syscall (specifically __sock_create) has the following
> code for the family:
>
> if (family < 0 || family >= NPROTO)
> return -EAFNOSUPPORT;
>
> And NPROTO is defined as decimal 39 (in 2.6.38). Hence, 0x200 as a family
> does not work for socket - the socket syscall would have returned an
> error.
>
> If for some reason the socket syscall uses AF_INET and diverts into IPv4,
> sin_family does not seem to be used unless you have a socket-specific bind
> function (e.g. RAW sockets).
It seems that bind(2) is not using the family. I checked on a system that is fixed vs
one that is not fixed. They both can transfer packets to one another. So, it looks like
you are right and there is only cosmetic problem.
> To make a final determination on the impact, I would check:
>
> - strace for socket syscall
>
> - tcpdump on the connection
These seem to be OK aside from strace not being able to decipher the family member to
bind. However, the calls to bind and connect are successful.
-Steve
prev parent reply other threads:[~2011-04-12 13:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-11 23:00 Bad bug in remote logging Steve Grubb
2011-04-12 3:18 ` Linda Knippers
2011-04-12 7:23 ` Stephan Mueller
2011-04-12 13:09 ` Steve Grubb [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201104120909.37444.sgrubb@redhat.com \
--to=sgrubb@redhat.com \
--cc=linux-audit@redhat.com \
--cc=smueller@atsec.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox