----- Original Message -----
> > The new imuxsock stores "pid", "uid" and "gid" into a "trusted"
> > subobject; shouldn't they go into the root object by default, so that
> > the JSON data can be used for Lumberjack storage directly without
> > modification in a template? (This also implies that mmjsonparse would
> > have to prevent modification of these values by content of the
> > message.)
>
> That's actually a good question. I see value in both. And with the
> flat vs. structured question being discussed again at CEE, I really
> don't know. Both makes sense. I have to admit (you may remember my
> presentation) that I have become tired by these discussions and
> rather code, as many others do (especially those that claim to solve
> all problems at once...). I don't object if we put them into the
> root directly, but for other use cases that'sprobably not as good
> (e.g. for quick access to all trusted properties, which then must be
> made on a field-by-field basis, what is especially bad from an
> extensibility PoV.
>
> In any case, I plan to make the container configurable. It's easy and
> leaves the choice to the user. But I had no time so far. Before
> doing that, I'll have to finish the rule engine/variable setting
> work.
I totally understand that the specification work is tiresome, and that the
resulting specification may not be great. Let me suggest some reasons why the
field names/placement should follow Lumberjack, even though the "trusted"
subobject is arguably a better design:
1) Consistency: Lumberjack is still very new, and fragmenting it now weakens
the utility of the specification.
2) Namespace issues on input: The "pid" field has a specific purpose, and
applications can be expected to not store data in there; the "trusted!pid"
field is not specified, so it should be available for applications to use. If
imuxsock adds "trusted!pid", there will be no way to record both the value that
was sent by the application and the value added by imuxsock at the same time.
On "output", we can solve the namespace disagreements by using templates, but
on "input", we don't have a similar structure renaming mechanism (and I don't
think we want one either). Arguably this can be solved by using e.g. a
"rsyslog!pid" namespace, but that's fragmenting the specification even more.
3) Trust, again: The trust issues in transport (TLS, mmjsonparse) can be
reliably solved. However, what about the log consumer? I'm currently writing
a log consumer library; where should it look for the "trusted" UID value? It
can obviously look in both "uid" and "trusted!uid", but which one should come
first? Which one is trusted? Which one can be supplied/spoofed by the
untrusted application? If a specific syslog implementation uses one of the
fields, is it also expected to always remove the other one? (Imagine syslog-ng
removing the "rsyslog" subtree from all incoming records...)
Mirek
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
