Incorrect default file permissions on the SoftHSM slots

When a slot is first initialized, for instance by running the "softhsm
--init-token --slot X" command, the sqlite database is created with the
uid:gid of the user that has runned the command. Default DAC
permissions are defined by the current umask of the running shell.

On my system, and I believe in most systems, the umask is too permissive
for the authorization levels required for such cryptographic containers.
By default, on my system, my slots are created with the 644
permissions, which makes my token world-readable.

It is my understanding that the sqlite_open function prototype does not
allow to specify the default permissions in case the sqlite database
does not exist.

I believe the current umask should be saved and a more restrictive umask
should be set before the sqlite_open call is performed. After the call,
the saved umask could be restored.

A restrictive umask of 117 would do, but I would prefer a paranoid umask
of 177. Investigations should however be performed: although it
enforces default permissions similar to /etc/ssl/private/* and
.ssh/id_rsa, it may break compatibility with existing systems.