Spaces in ACL values

Hello,

    As you know, most old squid.conf options cannot handle spaces in
parameter values as they do not support quoted strings or other ways of
escaping the space separator. A few new options, support quoted strings,
but many old ones do not. This is not going to be pretty because there
is no backward compatible way to introduce quoted strings (or
equivalent) that would work for every option. This email focuses on ACLs.

A good specific example is user_cert and ca_cert ACLs that are supposed
to match on various certificate attributes. In many, if not most, cases,
attributes like Organization Name and Common Name contain spaces. For
example:

    O: Google Inc
    O: Thawte Consulting (Pty) Ltd.
    CN: Thawte SGC CA

All of the above cannot be matched using user_cert and ca_cert ACLs.

I see a few reasonable ways to address this (see below for a list). They
all revolve around introducing support for "quoted strings" in ACL
values[1]. For loading files, they could all use file:"/path/name.ext"
syntax.

Each approach differs in how it addresses backward compatibility:

0) Screw backward compatibility and just start interpreting "quoted
strings" in ACL values as such. We can minimize breakage by detecting
unusual patterns such as quotes"in"the"middle and
"/quotes/without/any/spaces", treating them as the old parser would
(with a warning). We can also refuse to honor more than one value per
ACL when a value is quoted. Very few old configurations will be broken
by this, but I bet there will be some!

    # this will work OK
    acl badOne1 user_cert CN "Bad Guy"

    # this will also work as before, with a warning
    acl badOnes user_cert CN "/var/share/bad.guys"

    # this will be silently broken
    acl badOnes user_cert CN "/var/share/my bad guys list"

    # new file loading syntax required here:
    acl badOnes user_cert CN file:"/var/share/my bad guys list"

1a) Support -q or --quoted option with user_cert and ca_cert ACLs. The
option will allow the parser to interpret "quoted string" values as
quoted strings and not regular tokens. This is 100% backward compatible,
but requires an explicit option where the correct behavior would seem
obvious to most. Makes our configs noisier and less intuitive:

    acl badOne user_cert -q CN "Bad Guy"
    acl badOne user_cert -q CN file:"/bad/guys.txt"

1b) Support -q or similar option with all ACLs. As in (1a), the option
will allow the parser to interpret "quoted string" values as quoted
strings and not regular tokens. This is 100% backward compatible (if we
pick the right option name). Requires more work than (1a), but can be
introduced in stages.

    acl badOne ext_user -q "Bad Guy"
    acl badOne ext_user -q file:"/bad/guys.txt"

2) Add squid.conf directives to turn the new parsing behavior on and off
for a section of the configuration file. This is also 100% backward
compatible but difficult to introduce gradually -- admins will expect
everything inside a "quoted strings" section to support quoted strings,
and I am not 100% sure we can easily support that because different
options use different token parsers.

   # start new quoting support section
   configuration_value_parser quoted_strings
   # now just use the new quoting support
   acl badOne1 user_cert CN "Bad Guy"
   acl badOne2 ext_user "Bad Guy"

   # restore backward-compatible mode
   configuration_value_parser bare_tokens
   acl oldOne user_cert CN One" "Two and Four"

Any better ideas? Which approach do you think we should start working on?

N.B. The quoted strings will support macros and the usual escape
sequences. We already have code that handles those. We just need to
figure out the best way to introduce the quoted string syntax to old
directives.

Thank you,

Alex.
P.S. [1] I have considered using 'single quotes' instead of "double
quotes" to avoid clashes with the "/path/to/acl/values/file" syntax.
However, single quotes will not solve all the problems, and I think it
would be even worse to have two ways to quote strings. Also, we may want
reserve single quotes for other special purposes in the future.
Received on Thu Sep 13 2012 - 22:16:36 MDT