Rename @def to @objdef - it'll make future patches easier.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Since we're storing a virUUIDFormat'd string in our Hash Table, let's
modify the Lookup API to receive a formatted string as well.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

There's no need to separate, so just have one.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than overloading one function - split apart the logic to have
separate interfaces and local/private structures to manage the data
for which the helper is collecting.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Makes it a bit more clear what it is.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than 'nuuids' it should be 'maxuuids' and rather than 'got'
it should be 'nuuids'.  Alter the logic of the list traversal to
utilize those names.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than using "ret = -1" and cleanup processing, alter the return
path on failure to goto error and then just return the data.got.

In the error path, we no longer check for ret < 0, we just can free
anything added to the array and return -1 directly.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than dereferencing obj->def->X, create a local 'def' variable
that will dereference the def and use directly.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

When processing a virSecretPtr use 'secret' as a variable name.

When processing a virSecretObjPtr use 'obj' as a variable name.

When processing a virSecretDefPtr use 'def' as a variable name,
unless a distinction needs to be made with a 'newdef' such as
virSecretObjListAddLocked (which also used the VIR_STEAL_PTR macro
for the configFile and base64File).
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than have the caller check if !obj before calling, just check
in the function for !obj and return.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Make various virSecretObjList*Locked functions static and make
virSecretObjNew static since they're only called within virtsecretobj.c.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Shorten the time needed to keep the list lock and alter the cleanup
path to be more of an error path.

Utilize the the virObjectListFree function to handle the calls for
virObjectUnref on each list element and the VIR_FREE of the list
instead of open coding it.

Change the name of the virHashForEach callback to match the name
of the Export function with the Callback added onto it.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than have caller need to do it, have the object returned locked.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Commit id 'bb1fba62' neglected to set when creating the function.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

The public virSecret object has a single "usage_id" field
but the virSecretDef object has a different 'char *' field
for each usage type, but the code all assumes every usage
type has a corresponding single string. Get rid of the
pointless union in virSecretDef and just use "usage_id"
everywhere. This doesn't impact public XML format, only
the internal handling.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

There are couple of places where we have a string and want to
save it to a file. Atomically. In all those places we use
virFileRewrite() but also implement the very same callback which
takes the string and write it into temp file. This makes no
sense. Unify the callbacks and move them to one place.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add a new secret usage type known as "tls" - it will handle adding the
secret objects for various TLS objects that need to provide some sort
of passphrase in order to access the credentials.

The format is:

   <secret ephemeral='no' private='no'>
     <description>Sample TLS secret</description>
     <usage type='tls'>
       <name>mumblyfratz</name>
     </usage>
</secret>

Once defined and a passphrase set, future patches will allow the UUID
to be set in the qemu.conf file and thus used as a secret for various
TLS options such as a chardev serial TCP connection, a NBD client/server
connection, and migration.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Revert the remainder of commit id 'c8438010'

Add a new secret type known as "passphrase" - it will handle adding the
secret objects that need a passphrase without a specific username.

The format is:

   <secret ...>
     <uuid>...</uuid>
     ...
     <usage type='passphrase'>
       <name>mumblyfratz</name>
     </usage>
   </secret>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Use it instead of opendir everywhere we need to check for ENOENT.

It skips those directory entries.

Introduce a helper that only calls closedir if DIR* is non-NULL
and sets it to NULL afterwards.

Convert to virGetLastErrorMessage() in the rest of the code

Add a new helper that sanitizes error semantics of base64_encode_alloc.

Change 'ephemeral' to 'isephemeral' and 'private' to 'isprivate' since
both are bools.

Introduce the final accessor's to _virSecretObject data and move the
structure from virsecretobj.h to virsecretobj.c

The virSecretObjSetValue logic will handle setting both the secret
value and the value_size. Some slight adjustments to the error path
over what was in secretSetValue were made.

Additionally, a slight logic change in secretGetValue where we'll
check for the internalFlags and error out before checking for
and erroring out for a NULL secret->value. That way, it won't be
obvious to anyone that the secret value wasn't set rather they'll
just know they cannot get the secret value since it's private.

Introduce fetch and set accessor to the secretObj->def field for usage
by the driver to avoid the driver needing to know the format of virSecretObj

Move and rename the secretRewriteFile, secretSaveDef, and secretSaveValue
from secret_driver to virsecretobj

Need to make some slight adjustments since the secretSave* functions
called secretEnsureDirectory, but otherwise mostly just a move of code.

Move and rename secretDeleteSaved from secret_driver into virsecretobj and
split it up into two parts since there is error path code that looks to
just delete the secret data file

Move to secret_conf.c and rename to virSecretLoadAllConfigs. Also includes
moving/renaming the supporting virSecretLoad, virSecretLoadValue, and
virSecretLoadValidateUUID.

Add function to return counted listed of uuids to from the hashed secrets
object list. This will replace the guts of secretConnectListSecrets.

Add function to return a "match" filtered list of secret objects. This
function replaces the guts of secretConnectListAllSecrets.

Need to also move and make global virSecretUsageIDForDef since it'll
be used by both secret_driver.c and secret_conf.c

Add function to count the hashed secret obj list with filters. This
will replace the guts of secret_driver's secretConnectNumOfSecrets.

Add the functions to add/remove elements from the hashed secret obj list.
These will replace secret_driver functions secretAssignDef and secretObjRemove.

The virSecretObjListAddLocked will perform the necessary lookups and
decide whether to replace an existing hash entry or create a new one.
This includes setting up the configPath and base64Path as well as being
able to support the caller's need to restore from a previous definition
in case something goes wrong in the caller.

New API's including unlocked and Locked versions in order to be able
to use in either manner.

Support for searching hash object lists instead of linked lists will
replace existing secret_driver functions secretFindByUUID and
secretFindByUsage

Move virSecretObj from secret_driver.c to virsecretobj.h

To support being able to create a hashed secrets list, move the
virSecretObj to virsecretobj.h so that the code can at least find
the definition.

This should be a temporary situation while the virsecretobj.c code
is patched in order to support a hashed secret object while still
having the linked list support in secret_driver.c. Eventually, the
goal is to move the virSecretObj into virsecretobj.c, although it
is notable that the existing model from which virSecretObj was
derived has virDomainObj in src/conf/domain_conf.h and virNetworkObj
in src/conf/network_conf.h, so virSecretObj wouldn't be unique if
it were to remain in virsecretobj.h  Still adding accessors to fetch
and store hashed object data will be the end goal.

Add definitions and infrastucture in virsecretobj.c to create and
handle a hashed virSecretObj and virSecretObjList including the class,
object, lock setup, and disposal API's. Nothing will call these yet.

This infrastructure will replace the forward linked list logic
within the secret_driver, eventually.