On Tue, 9 Oct 2012, William Heinbockel wrote:
On Mon, 2012-10-08 at 16:51 -0700, david(a)lang.hm wrote:
> On Mon, 8 Oct 2012, david(a)lang.hm wrote:
>
> > exactly. If we support hierarchical structures, we can use a single tag,
> > if we make everything flat, we can reserve a prefix (ideally, a prefix
> > that translates to a subtree name so that people who want it flat can
> > treat it as if it's flat, people who want hierarchical can treat it as a
> > subtree)
> >
> > I would actually reserve two prefixes/subtree names
> >
> > The first for the tags that are generated by the logging infrastructure
> >
> > The second for a place to relocate any tags that are passed to us in a
> > reserved space.
> >
> > for the sake of argument, call these 'trusted.' and 'forged.' If
someone
> > submits something with trusted.uid, move it to forged.trusted.uid. If
> > someone submits something with forged.uid move it to forged.forged.uid.
> >
> >> If the prefix is unique there is a very low chance that the resolved
> >> fields would be overwritten unintentionally.
> >
> > exactly.
> >
> > Now, from the discussion a couple of weeks ago, people have a real hard
> > time with 'trusted' (arguments crop up about how much you can really
trust
> > it), so we need to pick something else.
> >
> > we could do lumberjack. for trusted and beaver. for forged :-) This is a
> > bit long, someone with more creativity can pick a couple of names.
>
Okay. I see where this is going.
David, sorry for the prior discussion of the "trusted" fields. I now
understand the point you were trying to make.
Generally, there are several groupings of fields:
* Application - the fields & structures added by the application when
the event record is created.
* Log system - the "trusted" fields added by the log service and system
* Other fields added by relays and event consumers
If we look at this, there is a natural nesting that occurs. First the
application data is records, with whatever fields they wish. Then, the
data is wrapped by the log system, similar to the syslog header vs.
content, though we probably want to be more flexible in the "header"
fields. I think this is some of what David was explaining with his
"trusted" fields. They are not "trusted" from the point of security,
but
the fact that they are placed there by a more trusted service and can be
thought of as being more reliable.
Later additions can then wrap the original events.
The only problem with this approach is that the most used information
from the original event ends up buried within this nesting of
Matryoshkas.
Maybe there is another way to solve this problem using a flat(ter)
structure?
It's only the 'trusted' stuff that needs 'protection', and even that
only
needs to be altered if it's bounced from machine to machine in a way that
isn't trusted by the admin.
for example, if you have trusted!pid and you send it via a trusted
mechanism, you don't change trusted!pid, you just add
trusted!authreason='TLS transport' trusted!relay!identity='key'
so it doesn't hae to get as nasty as you are thinking. additional data is
added, not nested.
David Lang