From owner-freebsd-arch Wed Nov 7 14: 3:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 8FC4437B419 for ; Wed, 7 Nov 2001 14:03:32 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fA7M3LB49523; Wed, 7 Nov 2001 17:03:21 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 7 Nov 2001 17:03:21 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: /etc/ttys, /var/run/utmp, ttyslot(3) and {get|put}utx* API In-Reply-To: <36293.1005168516@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 7 Nov 2001, Poul-Henning Kamp wrote: > In message , Robe > rt Watson writes: > > >> I guess the correct solution is to implement the Single Unix > >> "{get|put}utx" API backed by a db(3) file. > >> > >> http://www.opengroup.org/onlinepubs/007908799/xsh/endutxent.html > >> > >> Any comments ? > > > >"Yet another thread-unsafe API for managing databases"? > > Interesting point, I didn't think of that. On the other hand, I don't > see much point in multiple threads competing to fiddle this info since > they will all have the same session... Well, one of the problems with some of the other thread-unsafe APIs is when they get used by a library. For example, the ACL spec requires an acl_to_text() call, which (among other things) converts numeric uid's into usernames. The issue here is probably more of one of reentrance than thread-safety: when acl_to_text() invokes getpwuid(), it may interfere with the calling program. It's not impossible to imagine these types of calls interfering when used in a program such as a kde-ized or gnome-ized xdm. > Anyhow, I'm mightily leaning towards the idea that /var/run/utmp should > die and be moved into the session in the kernel, apart from all the > obvious things, this would make some interesting information available > in kernel dumps. I'm leaning that way also; there are some minor scoping issues, but I think they can be addressed by caching a struct ucred in the kernel session when the session is created, or possibly when the information is updated. This would allow virtual utmp entries to be ommitted based on (for example) what jail or MLS compartment the user is in. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message