On Wednesday 30 August 2006 16:41, Matt Anderson wrote: > >>I wanted to let you know that the "auid" field is shown twice, is it > >> going to remain this way? > > > > The one inside the msg should go away. Userspace apps cannot be trusted > > to set that correctly. > > We talked about this before Steve, mainly on #audit. The auid reported > in the audit record is the auid of cupsd which isn't relevant. Your > suggestion at the time was to add auid=N to the text of the record in > order to capture the security relevant auid of the user who submitted > the job.
Ok, that is the sender's loginuid. That is "sauid". > I was unaware of this rule. Is this rule intended to be system wide or > application wide? I'm pretty sure my USYS_CONFIG message doesn't match > any system wide format. Its intended to be system wide as much as possible. If there is explanation text in one that's not the other, that's ok. But when it comes to the name=value fields, they should be the same number and order. I have not been through all the userspace code since I've been doing more kernel and project management work lately. > I could remove the information from the success case, but I think its > good to know what label a job was exported with. Upon closer inspection > I now notice that acct= is also blank in the failure case. The auid is > known, but not the username that the user was operating under. acct is used when you do not know the uid. Example - pre-authentication. uid is always preferred since that means they've been authenticated. > I can go through and make most of the messages have the same format. > For the enqueue failure case there would just be blank fields, would > that be parsable? Sure. Use "?" so as to not consume diskspace. The easiest way to create uniformity is to create a function that takes all the parameters being logged as an argument. Then call it instead. > > Shouldn't there be a: was, is kinda thing? I think it should answer the > > basic question of: who changed it, from where, what changed, what was it, > > what is the new value, and was it successful. > > All messages that start with [Config] should only be issued once on > server startup. There is no way to record a previous value. Everything should have a default value - even at startup. :) > All the information you are talking about could occur while the CUPS server > is offline. If you wanted to capture that you would need a watch on the > /etc/cups/cupsd.conf file. Watching the file tells you the file changed, but not what changed. > classified is the leading banner page, none is the trailing banner. I > could make that snippet look like this: > banners=classified,none range=SystemHigh You mean header & footer? If so, you can have that as the name for each one. > That shouldn't confuse the parser too much since there wouldn't be any > white space between the banners. It looks like the LABEL_OVERRIDE > messages need to be changed to this format as well. In those messages > however there are two banner= fields. I'd try to avoid having the same field in a record twice. > The audit record has to capture what the user suggested, along with what the > server ended up using. user-header, final-header? > Would the parser handle banner= showing up twice? Not very well. > If not does anyone have a suggestion as to how to differentiate the two? Give separate names. BTW, this email thread could be public so that people like Klaus can chime in. He may have words of wisdom that make the job easier. -Steve -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
