> Then may be the fields that are generated by the interface
should
have a
> prefix that by convention is not used for other fields. For example
> instead of: pid - resolved_pid or something like. And IMO attempt to
> explicitly overwrite such field in the call should return an error
right
> away.
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.
I strongly like the prefix idea. It makes it easy to protect these fields.
HOWEVER, this raises another question. How far will we go protecting them? This issue was
also raised in the last discussion, but no solution was found.
The problem is with relaying. Let's say we have
App-A->local log socket-B->syslogd-C->remote syslogd
Where in C we have a network transfer. I assume that the syslogd will take
"trusted" data from the OS at point B and at the same time can prohibit forged
data from the app. HOWEVER, what happens at the remote syslogd after the network transfer
in C? Do we permit it to trust the data contained in the network package - or what do we
need to do?
IMHO, the solution is to accept that data, but recommend that the syslogd (any logger
meant) implementation will use different policies, e.g. trusted data may not be accepted
via regular transfer, but via TLS-protected transfer with mutual authentication (or at
least sender authentication).
Rainer