> Implementation Strategy > ======================= > > SQLite is already a component of Solaris and is used to store the SMF > service configuration. > > Existing access to lastlog is found in various PAM modules[5], sshd, > in.ftpd, finger, uucpd, pppd, and libresolv's PRNG mechanism. > Transitioning to this new mechanism would remove duplicate or > functionally equivalent from the various commands. Arguably, > libresolv should not use a private PRNG algorithm and should instead > rely upon /dev/random. > > According to utmpx(4), all access to utmpx and wtmpx files should be > through the various access and update library functions documented in > getutxent(3C). As such, these functions would become wrappers for > access to the SQLite database. Access to files other than > /var/adm/utmpx and /var/adm/wtmpx would still be permitted through > these library calls. Calls to updtwtmpx(3C) and utmpxname(3C) that > refer to /var/adm/utmpx or /var/adm/wtmpx would be intercepted and > directed to the SQLite database.
My first reaction is: uck. I understand the issues with the current utmpx and wtmpx formats that you point out, but preserving an API that's clearly designed around local files while actually making use of a database seems both awkward and likely to have backward-compatibility issues with API consumers who may think they're even more clever than your implementation. I'd rather see us either (a) continue to use local files or (b) deprecate the use of this whole mechanism in favor of something else. -- meem _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
