[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#747073: [cups-daemon] Doesn't work with systemd



On Thu, 25 Sep 2014 22:24:49 +0200 Didier 'OdyX' Raboud <odyx@debian.org> wrote:
>  ii) ListenStream with only the port number.
>      This works for the localhost ipv6 [::1] but it doesn't listen on 
>      127.0.0.1:631 but on :::631 . This implies that accessing
>      http://localhost:631/ doesn't spawn CUPS (of course, if you try
>      accessing http://[::1]:631/ first, then CUPS is spawned and the
>      IPv4 access works duing the 30 seconds, as cups has taken the port.

This seems like the fundamental bug here.  Listening on [::1]:631 with
BindIPv6Only=both *should* work equivalently to listening on
127.0.0.1:631 or localhost:631, and accessing http://localhost:631/
should then spawn CUPS rather than giving an error.

Regarding the "v4-over-v6 is widely seen as a major security problem" in
the CUPS bug report: per
https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02 , the
problem is using v4mapped addresses *on the wire*, not using such
addresses within a system to listen on a single socket.  The
recommendations from that draft say to avoid generating or receiving
IPv6 packets on the wire that contain v4mapped addresses, and that same
draft says "IPv4-mapped addresses are exclusively for uses local to a
node as specified in the basic API".

That said, I'd still like to see systemd capable of producing both a v4
and v6 listening socket, for whichever stacks the local system has,
omitting any that cannot exist because the stack doesn't exist.
(Ideally, systemd should only allow a ListenStream to fail because of a
missing stack, while still erroring on failures such as port conflicts.)

> Let's state it clearly: the core of the problem is that I think that
> "http://localhost:631/"; is a standard CUPS user interface and I'm not
> ready to make sure users (starting with me) change their muscle memory
> to use "http://ip6-localhost:631/"; or "http://[::1]:631/"; instead. How
> can we make this happen?

On a closely related note, I think we should fix hostname resolution so
that "localhost" resolves to both 127.0.0.1 and ::1, and vice versa,
with ip6-localhost remaining only as a compatibility fallback, if at
all.  http://localhost:631/ should work just fine over IPv6, just as any
other http or https URL does; if it doesn't, let's fix that.

- Josh Triplett


Reply to: