From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27115 invoked by alias); 14 Feb 2013 09:47:13 -0000 Received: (qmail 27107 invoked by uid 22791); 14 Feb 2013 09:47:12 -0000 X-SWARE-Spam-Status: No, hits=-7.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 14 Feb 2013 09:46:51 +0000 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r1E9koxb026736 for ; Thu, 14 Feb 2013 04:46:50 -0500 Date: Thu, 14 Feb 2013 09:47:00 -0000 From: Nathan Scott Reply-To: Nathan Scott To: systemtap@sourceware.org Message-ID: <1419415114.2640359.1360835210874.JavaMail.root@redhat.com> In-Reply-To: <1394151552.2635240.1360833812143.JavaMail.root@redhat.com> Subject: Possible systemtap/NSS areas of extension MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2013-q1/txt/msg00136.txt.bz2 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