It would. Quite a few options are hidden in the tracking files.

The problem is two-fold:

1. It will make the output even longer. In the case of something like IPA which can track as many as 14 certificates the output starts becoming unmanagable.
2. certmonger communicates over DBus so for each new chunk of attributes added I have to add a new DBus API for it. There is no way to pass a structure across DBus, I need to specify each data type.

So it just gets uglier and uglier.

What would you use the owner/group/mode output for? What's the use case?

I'm checking existing tracking requests to see why a program was complaining that it couldn't read its private key; in this case I noticed the key file had the wrong owner. At this point I saw that owner wasn't in the output of getcert list & I wanted to know whether this was because the tracking request had been created without the -o option had been missed out when getcert request was run, or whether something else had changed the owner of the file.

At that point I end up looking into /var/lib/certmonger/requests/ID to see that key_owner is present, so I fix up the ownership of the file to match.

So, when writing up a SOP for all that I have to include 'peer into the inner workings of certmonger to check that the owner/mode of the cert & key are as expected' & I find myself wishing this info would be displayed by 'getcert list' directly...

As for output: how about adding mode= and owner= alongside type= and file= to the existing key pair store and certificate lines? (Depending on how important you think it is to avoid breaking things that may parse the output of getcert list...)

Although it looks like cert/key owner/mode are not returned by any of the existing D-Bus methods, they are already exposed in the API as properties:

# busctl introspect org.fedorahosted.certmonger /org/fedorahosted/certmonger/requests/Request2 | grep -e owner -e perms
.cert-owner                         property  s         "radiusd"                                emits-change writable
.cert-perms                         property  x         0                                        emits-change writable
.key-owner                          property  s         "radiusd"                                emits-change writable
.key-perms                          property  x         0                                        emits-change writable

... so perhaps they could be grabbed from there without needing to add new methods to fetch the information.

(Sorta off topic: huh, I wonder why I see 0 for *-perms above... weird. The files have the right owner on disk. Maybe this means 'unset' and the defaults are 0600?)

Ok, you have me convinced :-)

I think it's a good idea to include it in the cert file/key and/or database line.

Also a good point about the existing properties. Maybe this won't be so bad after all.

And finally, yes, 0 means "no perms set".

    if (perms != 0) {
        if (fchmod(fd, perms) == -1) {
        ...
        }
    }

PR https://pagure.io/certmonger/pull-request/253

master: e326d70