netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martijn van Oosterhout <kleptog@svana.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: davem@davemloft.net, jchapman@katalix.com, netdev@oss.sgi.com
Subject: Re: PPP-over-L2TP kernel support, patch for review
Date: Wed, 8 Sep 2004 19:04:55 +1000	[thread overview]
Message-ID: <20040908090455.GF18285@svana.org> (raw)
In-Reply-To: <20040908084630.GA23117@gondor.apana.org.au>

[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]

On Wed, Sep 08, 2004 at 06:46:30PM +1000, Herbert Xu wrote:
> It can break because people often initialise the size of the
> address by doing sizeof(struct sockaddr_pppox).  For example,
> you'll see exactly this breakage in pppoe_getname in
> drivers/net/pppoe.c.

/me looks... *BLINK* Ugh, getname takes a length argument but it's
write only.

So, hypothetically, if I get passed a file descriptor through a UNIX
domain socket and do a getname on it, there is no way to guarentee that
it won't go past the buffer I've allocated. Who came up with this lame
API?

> IMHO this union was a silly idea to begin with.  Let's not prolong
> its life any further.

Well, I guess I'll have to agree to that. So, lets say we create two
new types, one for each version of the union, sockaddr_pppox_pppoe and
sockaddr_pppox_pppol2tp. Deprecate the current sockaddr_pppox
altogether (can't get rid of it now). Possibly create a new
sockaddr_pppox_generic for use in the actual pppox.c file. Sprinkle
some typecasts around to make the compiler happy and voila!

Then future userspace programs can use the structure appropriate for
them. Does removing the union change the alignment on any
architechture? Or will the dummy union have to stay in perpituity?

Seems fairly straight forward... I'll see if I have time to whip
something up...
-- 
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

  reply	other threads:[~2004-09-08  9:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-06 11:59 PPP-over-L2TP kernel support, patch for review James Chapman
2004-09-07 22:56 ` David S. Miller
2004-09-08  7:32   ` Martijn van Oosterhout
2004-09-08  8:17     ` Herbert Xu
2004-09-08  8:38       ` Martijn van Oosterhout
2004-09-08  8:46         ` Herbert Xu
2004-09-08  9:04           ` Martijn van Oosterhout [this message]
2004-09-08 10:04             ` Herbert Xu
  -- strict thread matches above, loose matches on Subject: below --
2004-09-06 11:55 James Chapman

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=20040908090455.GF18285@svana.org \
    --to=kleptog@svana.org \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=jchapman@katalix.com \
    --cc=netdev@oss.sgi.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;
as well as URLs for NNTP newsgroup(s).