Re: [PATCH] meta_header option

On 13/10/2012 5:21 p.m., Alex Rousskov wrote:
> On 10/12/2012 08:25 PM, Amos Jeffries wrote:
>
>> meta_note hi "Hello world"
>>
>> external_acl_type ... %note{hi} ...
>>
>> acl world note foo "Ehlo"
>>
>> logformat ... %note{hi} %note{foo}
>>
>> (where the helper recieves "... hi=\"Hello world\" ...") and responds
>> "OK foo="Ehlo")
> Are you sure that it is OK to treat everything the helper returns as
> annotation? We can do that, but I am a worried that it would then
> require a lot of extra work (on Squid and admin parts) to prevent
> certain annotations from being exposed to adaptation services and such.
> For example, most admins will not want password=foo to be exposed.
>
> I think we should separate/mark "exposable" annotations. For example,
>
> OK password=foo notes: key1=value1 key2=value2
>
> or, borrowing a trick from some Unix command line interfaces:
>
> OK password=foo -- key1=value1 key2=value2
>
>
> Note that if the admin does want to expose password, they can:
>
> OK password=foo -- key1=value1 password=foo
>
> Since Squid does not interpret annotations, there is no problem with
> repeating password twice in different "sections". However, we can also
> teach Squid to interpret known annotations to avoid such duplication
> when password exposure is desirable:
>
> OK -- key1=value1 password=foo

The sensitive ones are cert, group, user and password. And we are
constantly being asked how to pass those to ICAP anyway - so I think
allowing them to be passed is a wanted thing and if done safely will not
be a problem.

Why do you not supply a configuration option to specify the particular
notes *to* pass to an ICAP service rather than passing everything by
default? Like external ACL has today, the %EXT_TAG, %LOGIN etc are not
passed unless configured to happen. That ensures privacy and security by
default without limiting what could be passed.

>
>> There are only two real hangups I see ahead (the list you made earlier
>> is handling events for #2):
>>
>> 1) searching a list of meta keys for a certain name is slower than
>> loading value out of a object member field. We can optimize certain
>> popular keys though to avoid that - but still get the list maintenance
>> overheaders to retain the as-received ordering semantics.
> IMO, annotations are meant primarily for things Squid does not know
> about; things that admins introduce for their internal use. The above
> examples with the password key illustrate that the interface can also be
> used to expose things that Squid does know about, without any extra
> effort on our part (and no significant performance penalty either).
>
>
>> 2) the existing external ACL keys have no-replace / always-replace
>> semantics which we have to take care of specially for certain keys.
> Yes.
>
>
>> Overall I see the performance hit (1) as being the bigger issue. Since
>> workaround for both will likely be the same actions.
>>
>>>> Just had another idea. "key" or "keys".
>>> Since each annotation contains both a key and a value, it seems wrong to
>>> name the whole concept "key".
>> When you abstract a key into a value of another key (ie
>> key1=(key2:value2), yes it gets horrible. I'm not in favour of doing that.
>> Plan to have the key2 passed by name to the helper and the value2 as its
>> value and the abstraction issues all disappear along with the conceptual
>> problems it brings in.
> Sure, but I am thinking about things other than helper responses.

I know. For ICAP where its passed in mime headers. You can choose
whether to pass headers:

   Key1:value 1
   Key2:value2

or headers:

   Squid-Note: key1="value 1", key2=value2
   Squid-Note: key3="value 3"
   Squid-Note: key4=value4

... both of which fit mime format. With the former you have your
key:value input you seem to have been planning. With the latter you have
the common ( key '=' value ) syntax so its parser can be re-used between
Squid components (or the HTTP header one re-used here).

> note group Group1 !CONNECT fromGroup1
>
> is bearable (although "annotate" for the directive name would be better
> here), but
>
> key group Group1 !CONNECT fromGroup1
>
> looks pretty bad IMO because there is more than just key being set here.

Okay. "note" it is then.

Amos
Received on Sat Oct 13 2012 - 05:21:41 MDT