From owner-freebsd-current Mon Jan 6 18:12:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA21573 for current-outgoing; Mon, 6 Jan 1997 18:12:43 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id SAA21561; Mon, 6 Jan 1997 18:12:35 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA13434; Mon, 6 Jan 1997 19:02:58 -0700 From: Terry Lambert Message-Id: <199701070202.TAA13434@phaeton.artisoft.com> Subject: Re: utmp changes To: pst@shockwave.com (Paul Traina) Date: Mon, 6 Jan 1997 19:02:57 -0700 (MST) Cc: phk@critter.dk.tfs.com, jkh@freebsd.org, current@freebsd.org In-Reply-To: <199701031916.LAA15717@precipice.shockwave.com> from "Paul Traina" at Jan 3, 97 11:16:25 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > No what I wanted was a space for the key-name for ssh and a flag for the > fact that the session is encrypted. > > OK, then it was someone else who was talking about larger hostname sizes > and IP addresses. I'm more concerned about either making the space now, > or at least creating a "RESERVED" area (we should do that anyway) in utmp > and wtmp. > > To start the ball rolling, let me just suggest the following. I know it's > not pretty, and I'm not so sure that the remote ssh key belongs in utmp, > but this is what I conceive as changing. The big thing is I'd like to fix > the size of the utmp structure once and for all, and define the reserved > area as must-be-zero so we don't get in the mess we just got in ever again. :-( I would like to suggest a record size field for the next record. Alternatively, I'd like to suggest a version field, and a version tag on the structure names with a version flagged section for the unversioned name definition for compatability. Either one of these would let the utmp/wtmp record format change within a single file, and would allow future changes to be painless; the version tagged structure names would allow for simple conversion programs. A version would be more flexible, but lose backward compatability; a size would only allow growth, but could maintain general compatability of outdated tools running against a newer set of data. 8-(. I believe the ssh key is actually session information; session information does not belong in utmp/wtmp; especially, an ssh key does not belong in utmp, and wtmp is still a bit problematic, though less so than utmp. We need to abstract the ability to do session management; I should be able to attach any type of credential information to my current session credential, and all credential references for my user should refrence the addended credential (ie: refrence count it instead of duping it around for new logins by the same user, etc.). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.