Date: Mon, 30 Jun 2014 03:03:53 -0400
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Cc: alpine-devel@lists.alpinelinux.org
Subject: [alpine-devel] Re: [musl] Re: cups debugging, continued...ugly patch
Message-ID: <20140630070353.GG179@brightrain.aerifal.cx>
References: <20140629194829.GA1994@newbook>
 <20140630001201.GA14838@newbook>
 <20140630012830.GA16088@newbook>
 <20140630020311.GD179@brightrain.aerifal.cx>
 <20140630043512.GB16088@newbook>
 <20140630053426.GC16088@newbook>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140630053426.GC16088@newbook>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: Rich Felker <dalias@aerifal.cx>

On Sun, Jun 29, 2014 at 10:34:27PM -0700, Isaac Dunham wrote:
> Thanks to Rich's comment, I've found a solution that works here.
> The patch doesn't exactly look nice, though.

I agree it's ugly. The clean way to do it would be to use getaddrinfo
to request an AI_PASSIVE address for the desired family. Then you get
the right sockaddr type and size for free, and you can subsequently
fill in the port to try. That wouldn't work for AF_LOCAL (at least not
on musl) but this whole function makes no sense for AF_LOCAL.

Of course binding a reserved port like this is a serious security
smell -- it sounds like they're trying to facilitate port-based
authentication, which is unsafe if used for anything except localhost.

I would see if it's possible to remove the binding completely and have
it work. Remote lpd's would not be able to trust the ldp that omits
the bind based on its port, but this kind of trust is fundamentally
wrong and insecure anyway. If such a trust relationship is needed, a
proper authentication channel must be used.

Rich


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---