Possible systemtap/NSS areas of extension

[Nathan Scott <nathans at redhat dot com>]

Hi all,

I've been working with Dave Brolley recently to introduce
SSL/TLS support in PCP.  Its been sometimes convenient to
refer to the existing SSL/TLS support code in systemtap in
the process of doing this (this is to do with the compile-
server code, for reference, which uses the NSS TLS/SSL TLA
implementation).

As is always the case, the underlying libraries have moved
on a bit since the initial implementation, so I thought I'd
send out a list of potential areas we've found in which the
systemtap implementation might be extended / added to down
the track, in areas that have changed.

1. error codes
- the NSS libraries seem to have acquired a more flexible
  error code -> error string translation mechanism, that
  spans the nss, nspr and sec error code/string tables.
  systemtap maintains its own list in stapsslerr.h - this
  could nowadays be replaced with library calls, which'd
  remove the need to maintain this dup'd code->string map
  (which has become slightly out-of-date with new versions
  of NSS).

2. password handling
- there's a PK11_GetPassword interface which (apparently)
  provides an extensible way to extract a password from an
  unsuspecting user.  In stap-land, there's an open-coded
  implementation of a password request/response mechanism
  that deals only with someone entering passwords via the
  keyboard.  That case, and the more exotic cases of thumb
  readers, card readers, etc could potentially be handed
  off to NSS itself.

3. database formats
- NSS now supports databases in a number of different formats.
- In particular, shared databases (i.e. shared by applications
  on one machine) are now supported, via the sqlite format.
- I *think* systemtap will accidentally not allow these other
  formats, as its assuming the path specification really is a
  filesystem path.  Nowadays however, NSS will accept database
  format prefixed paths like "sql:/etc/pki/nssdb" and others
  too (dbm:, rdb: ... not looked more deeply into those though).
- cert_db_is_valid effectively checks via access(3) whether a
  given path is valid, which I think would cause these alternate
  (prefixed) NSS database formats to be rejected.

4. system-wide NSS database
- There appears to be a move toward consolidation of system/host
  certificate databases, at least for NSS-based databases.  An
  API has been added to facilitate transitioning to use of the
  system-wide shared SQL NSS database - NSSInitWithMerge.  It'd
  be an option for systemtap, if transitioning to the new form
  is considered a desirable feature at some point, to use this
  to merge the existing systemtap database with the system-wide
  database.

That's about it so far, I think.  If anything else comes up I'll
send further updates.

cheers.

--
Nathan