Limiting loading of PKCS#11 by architecture

[Kalev Lember]

Hi Stef,

Thanks for taking the time to think about the problem.


On 09/11/2011 12:17 PM, Stef Walter wrote:
> When packaging on Fedora, Kalev Lember brought up the issue that there's
> not really a way to limit p11-kit to only load modules for a given
> architecture.

Actually, this wasn't my original issue. My issue was that the
gnome-keyring package drops a configuration file in /etc/pkcs11/modules/
and that file was causing conflicts for multilib installations.

Fedora supports a multilib system where it is possible to install both
64 bit and 32 bit libraries on one system. The 32 bit libraries go in
/usr/lib and the 64 bit ones go in /usr/lib64. On a paper this all looks
very neat: the files are put in different directories so the 32 bit
library files should never conflict with the 64 bit ones.

However, some library packages also contain other files besides the
shared libraries. For example, a package could also contain a
configuration file in /etc, which has to be identical between the two
parallel installable packages.

In case of gnome-keyring, the two parallel installable packages look
like this (uninteresting files cut out for brevity):

gnome-keyring.i686:
/etc/pkcs11/modules/gnome-keyring-module
/usr/lib/pkcs11/gnome-keyring-pkcs11.so

gnome-keyring.x86_64
/etc/pkcs11/modules/gnome-keyring-module
/usr/lib64/pkcs11/gnome-keyring-pkcs11.so

These two packages both ship the gnome-keyring-module configuration
file, which specifies the full path to the pkcs11 module DSO. Having the
full path in the config file is a problem for multilib installations,
because the path differs for the two parallel installable architectures,
making the packages conflict.

32 bit gnome-keyring-module config file:
> module: /usr/lib/pkcs11/gnome-keyring-pkcs11.so
64 bit gnome-keyring-module config file:
> module: /usr/lib64/pkcs11/gnome-keyring-pkcs11.so


> When both 64-bit and 32-bit versions of a PKCS#11 library are installed
> then 64-bit processes should only load 64-bit modules, and vice versa.
> 
> I've put together a solution here:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=40775

As I understand it, this solution would rename the configuration files
so that they are different for 32 bit and 64 bit, and also introduce a
new config file parameter 'arch'.

Having a way to limit the loadable modules would probably be a nice to
have. However, doing it like that would introduce quite a bit of
complexity to the PKCS11 module (gnome-keyring) build systems, and/or to
the downstream distro packaging scripts. I'd rather avoid that.

I am not saying to scrap the arch-limiting idea; it would probably be a
nice option that the system administrator can set. But it should not be
something that each and every PKCS11 module installation script has to
deal with.


> I'm hoping to get this into p11-kit shortly, and have a new release. A
> bunch of distro's are releasing soon, so this would help make things work.
> 
> Let me know if you see any issues.

I'd like to propose another solution to the multilib problem.

Instead of requiring full paths in the config file, we could define a
standard directory for dropping pkcs11 modules (or symlinks) in, and
make it possible to specify relative paths to that directory.

gnome-keyring currently installs the modules in $libdir/pkcs11/ and this
might be a good candidate for a standard pkcs11 module installation
directory.

With relative paths, this:
> module: /usr/lib64/pkcs11/gnome-keyring-pkcs11.so
would change to:
> module: gnome-keyring-pkcs11.so

I'm sending a patch that implements the relative path support. If it
looks like something you think you could use, I'd be happy to also fix
up gnome-keyring's build.


-- 
Thanks,
Kalev