> ----- 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.
Sorry, it looks like I didn't make myself clear. I honestly believe in standards, after all this is why I spent 10+ years working on them ;) I was, however, under the impression that lumberjack does not have a final (enough) spec. I guess I took a little to less attention after spring. I need to refresh that. One main reason for the opinion was that lumberjack was supposed to follow CEE and CEE currently f*cks off on exactly the same questions which we considered solve (the n-th time;)) end of last year. > 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. Definitely. So as the lumberjack spec seems to be at least stable enough for RH, I'll change the default container. > > 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. This is only an issue if we consider the lumberjack spec stable, which I did not. > > 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...) Again, this all depends on a spec, so I need to fully agree. What you really needed to convince me on was the fact that we have a spec ;) I still think it is useful to give the end user the ability to specify a different container. If he does, he (hopefully) knows what he's doing. Are we in agreement? Rainer > 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
