[apparmor] [PATCH v2] json support for tools (logprof and genprof)
apparmor at cboltz.de
Sun Apr 2 14:02:03 UTC 2017
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
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
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.
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...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the AppArmor