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

[Christian Boltz]

Hello,

Am Donnerstag, 23. März 2017, 00:27:55 CEST schrieb Seth Arnold:
> On Wed, Mar 22, 2017 at 01:24:04PM -0500, Goldwyn Rodrigues wrote:
> > 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.
> 
> Hi Goldwyn, thanks for the update. It looks good to me with only the
> tineist of concerns -- first, this "one per line" idea. It feels like
> it'd be more resilient if instead of using multiple json documents,
> one per line, it'd be one json document with an array if an array is
> needed, and make the whitespace as unimportant as possible.

Each line needs to be handled by itsself, so I don't see a real problem 
here.

In many cases, only a single line (a prompt asking to allow something) 
will be printed.

If there are multiple lines (let's say, first a message to display and 
then a prompt), that message typically is a response to the previous 
step.

Maybe this is not technically perfect, but it makes things much easier 
on both ends of the pipe. 

Just as an example - printing a message ("$foo added to profile $bar") 
would need to be "buffered" because typically there's a prompt 
afterwards, and printing a prompt would need to make sure also to print 
that message. And that's assuming that there's always a prompt after 
printing a message, which isn't always true - saving all modified profiles 
will print a message, but aa-logprof exits afterwards.

As long as YaST knows that it has to read another line after displaying 
a message, I'm fine with having one json document per line. (Maybe we 
should add a "response_expected": True/False to all the json output?)

> Of course I expect yast to be the only consumer of this interface for
> a while, so if yast expects multiple json docs, then that's just what
> it ought to be. But if this interface is more flexible then I'd
> suspect that passing a single json document between processes would
> be more reliable.

I seriously hope we'll see an unittest as second customer ;-)

> > --- a/utils/aa-genprof
> > +++ b/utils/aa-genprof

> > +parser.add_argument('-j', '--json', action="store_true",
> > help=_('provide output in json format'))> 

> > --- a/utils/aa-logprof
> > +++ b/utils/aa-logprof

> > +parser.add_argument('-j', '--json', action='store_true',
> > help=_('provide the output in json format'))> 

> The other thing is that these two --help outputs are different; one is
> "the output" and the other is "output'. I think having them identical
> would make the tools feel more polished. (Every bit helps.)

Agreed, using the same text in both makes it more polished and also 
saves some translation work.


Regards,

Christian Boltz
-- 
Wenn Du Dich weiter doof stellst, dann:
Warning: loading builtin philipp-cool-down.dll. Couldn't be loaded!
Expect trouble!!!                 [Philipp Zacharias in suse-linux]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20170402/5ecb005d/attachment.pgp>