[apparmor] [PATCH 2/2] json support for tools (logprof and genprof)

Goldwyn Rodrigues rgoldwyn at suse.de
Fri Apr 14 14:20:27 UTC 2017



On 04/13/2017 04:52 PM, Christian Boltz wrote:
> Hello,
> 
> Am Donnerstag, 13. April 2017, 05:55:54 CEST schrieb Goldwyn Rodrigues:
>> From: Goldwyn Rodrigues <rgoldwyn at suse.com>
>>
>> This adds JSON support for tools in order to be able to talk to
>> other utilities such as Yast.
>>
>> The json is one per line, in order to differentiate between multiple
>> records. This is based on work presented by Christian Boltz some time
>> back.
>>
>> Signed-off-by: Goldwyn Rodrigues <rgoldwyn at suse.com>
>> ---
>> Changes since v1:
>>  - implementation of set_json_mode(), write_json()
>>  - Changed the way output is provided to keep input the same. This
>> would write in either of two formats: text or json, but will keep
>> input the same. This helps in keeping localizations in place. I so
>> wish UI was a class.. - Removed all yast calls.
>>
>> Changes since v2:
>>  - use if UI_mode == json else, to make sure some output is returned
>> in case of faulty UI_mode.
>>  - spelling correction yesnocancal
>>  - Added default_key
>>  - added dialog entry in all communication, to identify the kind of
>> json output. 
> 
> We just discussed this a bit on IRC. 'dialog' is a very good idea and 
> can be helpful to ensure we don't break anything.
> 
> I'd even say we should never change the parameters of existing 'dialog' 
> types. If changes are needed, we should create a new 'dialog' type 
> instead. (I'm speaking about released versions here - changes for 
> dialogs only in bzr are not that problematic.)
> 
> 
> Also, it would be helpful to print out the json scheme version at the 
> beginning. This can help clients to break early (at startup, if the json 
> version is too new for them) instead of breaking later when receiving a 
> new ("unknown") 'dialog' type.
> 
> Just as an idea, set_json_mode() could do
> 
>     jsonout = {'dialog': 'apparmor-json-version', 'data': '2.12'}
>     write_json(jsonout)
> 
> '2.12' obviously matches the next AppArmor release. It will only be 
> changed if the json interface changes, so if it turns out your patch is 
> good enough for the next 50 years, it will stay at '2.12' forever ;-)
> 
> If you think a simple number is easier to handle - I'm also fine with 
> version '1' ;-)

I think apparmor json version makes sense, though aa-status --json
supplies version as
"version": "1"

Would you prefer to be uniform?

> 
> IMHO the client (YaST) should error out if the version is newer than 
> what it supports - that's better than breaking somewhere in the middle 
> of an aa-logprof run.

Yes, that's right.

> 
> BTW: Adding a summary of the above as comment to ui.py would be a good 
> idea.
> 
> 
> You can do this in a follow-up patch - it wouldn't be the first time we 
> see a 3/2 patch ;-)
> (If you prefer to update this patch, please tell me.)

I would prefer to update this one. It is best if we have everything
sorted out before we put this in.

> 
> 
>> diff --git a/utils/apparmor/ui.py b/utils/apparmor/ui.py
>> index f25fff3..c4462b0 100644
>> --- a/utils/apparmor/ui.py
>> +++ b/utils/apparmor/ui.py
> 
>> @@ -44,12 +54,18 @@ def getkey():
>>
>>  def UI_Info(text):
>>      debug_logger.info(text)
>> -    if UI_mode == 'text':
>> +    if UI_mode == 'json':
>> +        jsonout = {'dialog': 'info', 'data': text}
>> +        write_json(jsonout)
>> +    else: # text mode
> 
> Minor nitpicking: python coding styles expect _two_ spaces between code 
> and comments, so this line should be
> 
> +    else:  # text mode
> 
> (Applies to several comments in your patch.)
> 
>> @@ -324,6 +348,17 @@ class PromptQuestion(object):
>>          function_regexp += ')$'
>>
>>          ans = 'XXXINVALIDXXX'
>> +        hdict = dict()
>> +        jsonprompt = {
>> +            'dialog': 'promptuser',
>> +            'title': title,
>> +            'headers': hdict,
>> +            'explanation': explanation,
>> +            'options': options,
>> +            'menu_items': menu_items,
>> +	    'default_key': default_key,
> 
> The last line has a whitespace issue - tab instead of spaces?

Yeah, vim setcindent set as default :(

> 
> 
> BTW: Don't forget to let YaST send the selected option in this dialog, 
> and also make sure it works if more than 9 options are available.
> Hint: It might be a good idea to provide the response as json {'option': 
> <selected option>, 'menu_item': <pressed button>} in this case.
> (Again, this could be a follow-up patch.)

Hmm, that makes sense. I will update this patch, but it will be quite a
while because I will have to make the other interface as well. But I
think it is best to get things right.

> 
> 
> The attached file contains your patch with the whitespace issues fixed
> (no other changes).
> 
> If you promise to send a follow-up patch that adds the json version info 
> (and the comments about interface stability), I'm ready to give this 
> patch (with the whitespace fixes as listed above) my
>     Acked-by: Christian Boltz <apparmor at cboltz.de>
> 
> If you prefer to send a v4 of this patch, tell me ;-)
> 

I'd prefer v4.

Thanks for the review.

-- 
Goldwyn



More information about the AppArmor mailing list