Comment 8 for bug 1206254

John Dennis (jdennis-a) wrote :

Re comment #7, it's not the granting of read permission which is the issue, it's the write permission. Being able to read the serial or index file is not a security issue. However ...

I've done a lot more research into what happens with these files.

When the openssl ca command is run it updates the serial and index file, plus makes backups. In addition it writes other files into the ca directory. These new files get the ownership and group of the process running the command. Each appears to be given mode 0666 which is masked off with the umask. Normal users typically have a umask of 02, and root has a umask of 022. Because of the way the ca command backs up the serial and index file (renaming the previous file and writing a new version) whatever permissions and ownership we give those files are lost when the command runs (although the first backup retains it).

Thus the issue of ownership and permissions on the serial and index files has less to do with how we initially create the files and more with who runs the command. The command is run via keystone-manage ssl_setup | pki_setup.

keystone-manage ssl_setup | pki_setup have command line args for the keystone-user and keystone-group (symbolic user and group names). Until recently these were not required. In commit f0a9affca on 5/18/203 on master the user & group command line args became mandatory if the command was executed as root.

Devstack's runs keystone-manage but does not specify a user or group (even if run as root).

The Red Hat install guide recommends creating a keystone system user:group and then running keystone-manage passing the keystone user:group. I presume the other install guides do the same.

Internally the keystone user:group is only used to chown files and directories if it's running as root.

However there is a bug in, it passes the symbolic name of the user and group to chmod instead of the uid and gid respectively. This throws an exception and the setup process terminates early. I will file a separate bug on this.

The ownership and permissions of the CA files modified by the openssl ca depend on who runs the keystone-mange command.

You can run the keystone-manage command more than once. It will reset the ownship and permissions on many of the files (how depends on whether it was run as root). However it omits resetting the ownership and permission on the CA key and CA cert. Thus if you try to fix unintended ownership/permissions by running the keystone-manage command again one of the most critical files, the CA key will not be updated.

For reasons I don't understand only the group is set on directories, not the owner.

I would think root:keystone would be a better ownership than the recommended keystone:keystone.

The CA key and signing key are given 0400 but anyone with write access to the directory can rename or delete the keys. The signing key is put in the directory ssl/pprivate with permission 0700, the CA key is put in the ssl/certs directory which has permission 0755. Why isn't the CA key also in the ssl/private directory instead of the general certs directory? Certs and keys are not the same thing, certs are public while keys should be private. Although the CA key can only be read by it's owner and only the owner of the two directories have write access it means both keys are protected from reading/renaming/deletion by anyone but the owner, but it's not best practice.


The ownership and modes we give to the index and serial file is irrelevant because the openssl command recreates those files using the ownership and umask associated with the process which runs the keystone manage command.

Trying to specify the owner:group via the keystone-user keystone-group command line arguments causes the entire command to fail.

Ownership of the files depends on the user who last ran the keystone-manage command as opposed to being deterministic.

The ownership of the critical CA key file is never updated by keystone-manage.

Directory ownerhips are never set.

Normal files are given execute permission.

I question the design decision which permits any untrusted user to create a CA and signing key which is then used to control the entire security of the OpenStack deployment.