[PATCH] Added warning about redefinition of listen socket protocol options
Maxim Dounin
mdounin at mdounin.ru
Wed Jan 25 21:29:28 UTC 2023
Hello!
On Mon, Jan 23, 2023 at 02:21:33PM +0400, Sergey Kandaurov wrote:
> > On 31 Dec 2022, at 18:35, Maxim Dounin <mdounin at mdounin.ru> wrote:
> >
> > # HG changeset patch
> > # User Maxim Dounin <mdounin at mdounin.ru>
> > # Date 1672497248 -10800
> > # Sat Dec 31 17:34:08 2022 +0300
> > # Node ID c215d5cf25732ece1819cf1cd48ebb480bb642c7
> > # Parent 07b0bee87f32be91a33210bc06973e07c4c1dac9
> > Added warning about redefinition of listen socket protocol options.
> >
> > The "listen" directive in the http module can be used multiple times
> > in different server blocks. Originally, it was supposed to be specified
> > once with various socket options, and without any parameters in virtual
> > server blocks. For example:
> >
> > server { listen 80 backlog=1024; server_name foo; ... }
> > server { listen 80; server_name bar; ... }
> > server { listen 80; server_name bazz; ... }
> >
> > The address part of the syntax ("address[:port]" / "port" / "unix:path")
> > uniquely identifies the listening socket, and therefore is enough for
> > name-based virtual servers (to let nginx know that the virtual server
> > accepts requests on the listening socket in question).
> >
> > To ensure that listening options do not conflict between virtual servers,
> > they were allowed only once. For example, the following configuration
> > will be rejected ("duplicate listen options for 0.0.0.0:80 in ..."):
> >
> > server { listen 80 backlog=1024; server_name foo; ... }
> > server { listen 80 backlog=512; server_name bar; ... }
> >
> > At some point it was, however, noticed, that it is sometimes convenient
> > to repeat some options for clarity. In nginx 0.8.51 the "ssl" parameter
> > was allowed to be specified multiple times, e.g.:
> >
> > server { listen 443 ssl backlog=1024; server_name foo; ... }
> > server { listen 443 ssl; server_name bar; ... }
> > server { listen 443 ssl; server_name bazz; ... }
> >
> > This approach makes configuration more readable, since SSL sockets are
> > immediately visible in the configuration. If this is not needed, just the
> > address can still be used.
> >
> > Later, additional protocol-specific options similar to "ssl" were
> > introduced, notably "http2" and "proxy_protocol". With these options,
> > one can write:
> >
> > server { listen 443 ssl backlog=1024; server_name foo; ... }
> > server { listen 443 http2; server_name bar; ... }
> > server { listen 443 proxy_protocol; server_name bazz; ... }
> >
> > The resulting socket will use ssl, http2, and proxy_protocol, but this
> > is not really obvious from the configuration.
> >
> > To ensure such misleading configurations are not allowed, nginx now
> > warns as long as the "listen" directive is used with options different
>
> nitpicking:
>
> "ensure .. are not allowed" and "warns" don't seem to be equally strong.
> As such, I'd rewrite to something like:
>
> To emphasize such misleading configurations are discouraged, nginx now
Thanks, changed.
> > from the options previously used if these are potentially confusing.
>
> Not really confident what "these" refers to.
>
> s/these/they/ ?
I don't think that there is much difference between "these" and
"they" when it comes to what they refer to. Either way, "if this
is potentially confusing" is probably better and unambiguously
refers to the fact that the "listen" directive is used with the
different options. Changed.
> > In particular, the following configurations are allowed:
> >
> > server { listen 8401 ssl backlog=1024; server_name foo; }
> > server { listen 8401 ssl; server_name bar; }
> > server { listen 8401 ssl; server_name bazz; }
> >
> > server { listen 8402 ssl http2 backlog=1024; server_name foo; }
> > server { listen 8402 ssl; server_name bar; }
> > server { listen 8402 ssl; server_name bazz; }
> >
> > server { listen 8403 ssl; server_name bar; }
> > server { listen 8403 ssl; server_name bazz; }
> > server { listen 8403 ssl http2; server_name foo; }
> >
> > server { listen 8404 ssl http2 backlog=1024; server_name foo; }
> > server { listen 8404 http2; server_name bar; }
> > server { listen 8404 http2; server_name bazz; }
> >
> > server { listen 8405 ssl http2 backlog=1024; server_name foo; }
> > server { listen 8405 ssl http2; server_name bar; }
> > server { listen 8405 ssl http2; server_name bazz; }
> >
> > server { listen 8406 ssl; server_name foo; }
> > server { listen 8406; server_name bar; }
> > server { listen 8406; server_name bazz; }
> >
> > And the following configurations will generate warnings:
> >
> > server { listen 8501 ssl http2 backlog=1024; server_name foo; }
> > server { listen 8501 http2; server_name bar; }
> > server { listen 8501 ssl; server_name bazz; }
> >
> > server { listen 8502 backlog=1024; server_name foo; }
> > server { listen 8502 ssl; server_name bar; }
> >
> > server { listen 8503 ssl; server_name foo; }
> > server { listen 8503 http2; server_name bar; }
> >
> > server { listen 8504 ssl; server_name foo; }
> > server { listen 8504 http2; server_name bar; }
> > server { listen 8504 proxy_protocol; server_name bazz; }
> >
> > server { listen 8505 ssl http2 proxy_protocol; server_name foo; }
> > server { listen 8505 ssl http2; server_name bar; }
> > server { listen 8505 ssl; server_name bazz; }
> >
> > server { listen 8506 ssl http2; server_name foo; }
> > server { listen 8506 ssl; server_name bar; }
> > server { listen 8506; server_name bazz; }
> >
> > server { listen 8507 ssl; server_name bar; }
> > server { listen 8507; server_name bazz; }
> > server { listen 8507 ssl http2; server_name foo; }
> >
> > server { listen 8508 ssl; server_name bar; }
> > server { listen 8508; server_name bazz; }
> > server { listen 8508 ssl backlog=1024; server_name foo; }
> >
> > server { listen 8509; server_name bazz; }
> > server { listen 8509 ssl; server_name bar; }
> > server { listen 8509 ssl backlog=1024; server_name foo; }
> >
>
> 15 examples of dos and don'ts looks slightly excessive.
> The accurate description (such as provided by you below) allows
> to reduce most of them to e.g. four common invalid configurations:
>
> A lesser option set with socket option:
>
> server { listen 8443 backlog=1024; server_name foo; }
> server { listen 8443 http2; server_name bar; }
>
> The main option set is repeated at least twice:
>
> server { listen 127.0.0.1:8443; server_name foo; }
> server { listen 127.0.0.1:8443 ssl; server_name bar; }
> server { listen 127.0.0.1:8443 ssl; server_name baz; }
>
> Option sets partially overlap:
>
> server { listen 127.0.0.1:8443 ssl; server_name foo; }
> server { listen 127.0.0.1:8443 http2; server_name bar; }
>
> More than two option sets:
>
> server { listen 127.0.0.1:8443 http2 ssl; server_name foo; }
> server { listen 127.0.0.1:8443 http2; server_name bar; }
> server { listen 127.0.0.1:8443 ssl; server_name baz; }
While your approach might be better from documentation point
of view, the way it is currently described in the commit log is
how it was designed: from the examples of valid and invalid
configurations.
My current working tests contain 18 valid and 22 invalid
configurations, derived from the ones provided in the commit log
with additional shuffling. But since these are derived I've
decided to avoid providing all of them in the commit log.
> > The basic idea is that at most two sets of protocol options are allowed:
> > the main one (with socket options, if any), and a shorter one, with options
> > being a subset of the main options, repeated for clarity. As long as the
> > shorter set of protocol options is used, all listen directives except the
> > main one should use it.
>
> I'd move this paragraph somewhere before examples, as this is the most
> specific description of things actually changed.
This paragraph summarizes changes made to address the issue
described, and I don't think moving it will improve things.
> BTW, while reviewing I caught sort of a bug.
> As I understand the above explanation, if there are both full and short
> sets present, then at most one listen directive can have the full set,
> while shorter sets can be repeated. If so, then with the proposed patch
> the next configuration is expectedly invalid:
>
> server { listen 127.0.0.1:8443 ssl; server_name foo; }
> server { listen 127.0.0.1:8443 ssl; server_name bar; }
> server { listen 127.0.0.1:8443; server_name baz; }
>
> This is expected since first two servers with same options are
> interpreted as a short form (with full form seen potentially later on),
> but 3rd server has lesser options, which is caught by this check:
> (addr[i].protocols_set && protocols != addr[i].protocols)
> Which is interpreted as:
> "this server has a lesser set that doesn't match a a shorter set".
>
> Now, if 3rd server is moved first, configuration starts to pass:
>
> server { listen 127.0.0.1:8443; server_name baz; }
> server { listen 127.0.0.1:8443 ssl; server_name foo; }
> server { listen 127.0.0.1:8443 ssl; server_name bar; }
>
> This is because after (now) 2nd server, it is parsed as:
> 1st server has a short form, and 2nd server has a full form.
> Then 3rd server goes to "the same options" case. This also
> overwrites the remembered shorter set in addr[i].protocols.
>
> I guess an additional check should be added to address this.
> It is similar to the "options removed" case and ensures that
> the repeated options set actually matches a shorter set:
>
> diff --git a/src/http/ngx_http.c b/src/http/ngx_http.c
> --- a/src/http/ngx_http.c
> +++ b/src/http/ngx_http.c
> @@ -1345,7 +1345,9 @@ ngx_http_add_addresses(ngx_conf_t *cf, n
>
> /* the same options */
>
> - if (lsopt->set && addr[i].protocols_changed) {
> + if ((lsopt->set && addr[i].protocols_changed)
> + || (addr[i].protocols_set && protocols != addr[i].protocols))
> + {
> ngx_conf_log_error(NGX_LOG_WARN, cf, 0,
> "protocol options redefined for %V",
> &addr[i].opt.addr_text);
Thanks for catching this, applied.
Updated patch:
# HG changeset patch
# User Maxim Dounin <mdounin at mdounin.ru>
# Date 1674624978 -10800
# Wed Jan 25 08:36:18 2023 +0300
# Node ID 1619d1563c3231d4283937610ce97aa1e3824fb8
# Parent c7e103acb409f0352cb73997c053b3bdbb8dd5db
Added warning about redefinition of listen socket protocol options.
The "listen" directive in the http module can be used multiple times
in different server blocks. Originally, it was supposed to be specified
once with various socket options, and without any parameters in virtual
server blocks. For example:
server { listen 80 backlog=1024; server_name foo; ... }
server { listen 80; server_name bar; ... }
server { listen 80; server_name bazz; ... }
The address part of the syntax ("address[:port]" / "port" / "unix:path")
uniquely identifies the listening socket, and therefore is enough for
name-based virtual servers (to let nginx know that the virtual server
accepts requests on the listening socket in question).
To ensure that listening options do not conflict between virtual servers,
they were allowed only once. For example, the following configuration
will be rejected ("duplicate listen options for 0.0.0.0:80 in ..."):
server { listen 80 backlog=1024; server_name foo; ... }
server { listen 80 backlog=512; server_name bar; ... }
At some point it was, however, noticed, that it is sometimes convenient
to repeat some options for clarity. In nginx 0.8.51 the "ssl" parameter
was allowed to be specified multiple times, e.g.:
server { listen 443 ssl backlog=1024; server_name foo; ... }
server { listen 443 ssl; server_name bar; ... }
server { listen 443 ssl; server_name bazz; ... }
This approach makes configuration more readable, since SSL sockets are
immediately visible in the configuration. If this is not needed, just the
address can still be used.
Later, additional protocol-specific options similar to "ssl" were
introduced, notably "http2" and "proxy_protocol". With these options,
one can write:
server { listen 443 ssl backlog=1024; server_name foo; ... }
server { listen 443 http2; server_name bar; ... }
server { listen 443 proxy_protocol; server_name bazz; ... }
The resulting socket will use ssl, http2, and proxy_protocol, but this
is not really obvious from the configuration.
To emphasize such misleading configurations are discouraged, nginx now
warns as long as the "listen" directive is used with options different
from the options previously used if this is potentially confusing.
In particular, the following configurations are allowed:
server { listen 8401 ssl backlog=1024; server_name foo; }
server { listen 8401 ssl; server_name bar; }
server { listen 8401 ssl; server_name bazz; }
server { listen 8402 ssl http2 backlog=1024; server_name foo; }
server { listen 8402 ssl; server_name bar; }
server { listen 8402 ssl; server_name bazz; }
server { listen 8403 ssl; server_name bar; }
server { listen 8403 ssl; server_name bazz; }
server { listen 8403 ssl http2; server_name foo; }
server { listen 8404 ssl http2 backlog=1024; server_name foo; }
server { listen 8404 http2; server_name bar; }
server { listen 8404 http2; server_name bazz; }
server { listen 8405 ssl http2 backlog=1024; server_name foo; }
server { listen 8405 ssl http2; server_name bar; }
server { listen 8405 ssl http2; server_name bazz; }
server { listen 8406 ssl; server_name foo; }
server { listen 8406; server_name bar; }
server { listen 8406; server_name bazz; }
And the following configurations will generate warnings:
server { listen 8501 ssl http2 backlog=1024; server_name foo; }
server { listen 8501 http2; server_name bar; }
server { listen 8501 ssl; server_name bazz; }
server { listen 8502 backlog=1024; server_name foo; }
server { listen 8502 ssl; server_name bar; }
server { listen 8503 ssl; server_name foo; }
server { listen 8503 http2; server_name bar; }
server { listen 8504 ssl; server_name foo; }
server { listen 8504 http2; server_name bar; }
server { listen 8504 proxy_protocol; server_name bazz; }
server { listen 8505 ssl http2 proxy_protocol; server_name foo; }
server { listen 8505 ssl http2; server_name bar; }
server { listen 8505 ssl; server_name bazz; }
server { listen 8506 ssl http2; server_name foo; }
server { listen 8506 ssl; server_name bar; }
server { listen 8506; server_name bazz; }
server { listen 8507 ssl; server_name bar; }
server { listen 8507; server_name bazz; }
server { listen 8507 ssl http2; server_name foo; }
server { listen 8508 ssl; server_name bar; }
server { listen 8508; server_name bazz; }
server { listen 8508 ssl backlog=1024; server_name foo; }
server { listen 8509; server_name bazz; }
server { listen 8509 ssl; server_name bar; }
server { listen 8509 ssl backlog=1024; server_name foo; }
The basic idea is that at most two sets of protocol options are allowed:
the main one (with socket options, if any), and a shorter one, with options
being a subset of the main options, repeated for clarity. As long as the
shorter set of protocol options is used, all listen directives except the
main one should use it.
diff --git a/src/http/ngx_http.c b/src/http/ngx_http.c
--- a/src/http/ngx_http.c
+++ b/src/http/ngx_http.c
@@ -1228,7 +1228,8 @@ static ngx_int_t
ngx_http_add_addresses(ngx_conf_t *cf, ngx_http_core_srv_conf_t *cscf,
ngx_http_conf_port_t *port, ngx_http_listen_opt_t *lsopt)
{
- ngx_uint_t i, default_server, proxy_protocol;
+ ngx_uint_t i, default_server, proxy_protocol,
+ protocols, protocols_prev;
ngx_http_conf_addr_t *addr;
#if (NGX_HTTP_SSL)
ngx_uint_t ssl;
@@ -1264,12 +1265,18 @@ ngx_http_add_addresses(ngx_conf_t *cf, n
default_server = addr[i].opt.default_server;
proxy_protocol = lsopt->proxy_protocol || addr[i].opt.proxy_protocol;
+ protocols = lsopt->proxy_protocol;
+ protocols_prev = addr[i].opt.proxy_protocol;
#if (NGX_HTTP_SSL)
ssl = lsopt->ssl || addr[i].opt.ssl;
+ protocols |= lsopt->ssl << 1;
+ protocols_prev |= addr[i].opt.ssl << 1;
#endif
#if (NGX_HTTP_V2)
http2 = lsopt->http2 || addr[i].opt.http2;
+ protocols |= lsopt->http2 << 2;
+ protocols_prev |= addr[i].opt.http2 << 2;
#endif
if (lsopt->set) {
@@ -1299,6 +1306,57 @@ ngx_http_add_addresses(ngx_conf_t *cf, n
addr[i].default_server = cscf;
}
+ /* check for conflicting protocol options */
+
+ if ((protocols | protocols_prev) != protocols_prev) {
+
+ /* options added */
+
+ if ((addr[i].opt.set && !lsopt->set)
+ || addr[i].protocols_changed
+ || (protocols | protocols_prev) != protocols)
+ {
+ ngx_conf_log_error(NGX_LOG_WARN, cf, 0,
+ "protocol options redefined for %V",
+ &addr[i].opt.addr_text);
+ }
+
+ addr[i].protocols = protocols_prev;
+ addr[i].protocols_set = 1;
+ addr[i].protocols_changed = 1;
+
+ } else if ((protocols_prev | protocols) != protocols) {
+
+ /* options removed */
+
+ if (lsopt->set
+ || (addr[i].protocols_set && protocols != addr[i].protocols))
+ {
+ ngx_conf_log_error(NGX_LOG_WARN, cf, 0,
+ "protocol options redefined for %V",
+ &addr[i].opt.addr_text);
+ }
+
+ addr[i].protocols = protocols;
+ addr[i].protocols_set = 1;
+ addr[i].protocols_changed = 1;
+
+ } else {
+
+ /* the same options */
+
+ if ((lsopt->set && addr[i].protocols_changed)
+ || (addr[i].protocols_set && protocols != addr[i].protocols))
+ {
+ ngx_conf_log_error(NGX_LOG_WARN, cf, 0,
+ "protocol options redefined for %V",
+ &addr[i].opt.addr_text);
+ }
+
+ addr[i].protocols = protocols;
+ addr[i].protocols_set = 1;
+ }
+
addr[i].opt.default_server = default_server;
addr[i].opt.proxy_protocol = proxy_protocol;
#if (NGX_HTTP_SSL)
@@ -1355,6 +1413,9 @@ ngx_http_add_address(ngx_conf_t *cf, ngx
}
addr->opt = *lsopt;
+ addr->protocols = 0;
+ addr->protocols_set = 0;
+ addr->protocols_changed = 0;
addr->hash.buckets = NULL;
addr->hash.size = 0;
addr->wc_head = NULL;
diff --git a/src/http/ngx_http_core_module.h b/src/http/ngx_http_core_module.h
--- a/src/http/ngx_http_core_module.h
+++ b/src/http/ngx_http_core_module.h
@@ -274,6 +274,10 @@ typedef struct {
typedef struct {
ngx_http_listen_opt_t opt;
+ unsigned protocols:3;
+ unsigned protocols_set:1;
+ unsigned protocols_changed:1;
+
ngx_hash_t hash;
ngx_hash_wildcard_t *wc_head;
ngx_hash_wildcard_t *wc_tail;
--
Maxim Dounin
http://mdounin.ru/
More information about the nginx-devel
mailing list