From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Wed, 25 May 2005 01:32:04 -0400 From: Russ Cox To: 9fans <9fans@cse.psu.edu> Subject: Re: [9fans] 9grid.us In-Reply-To: <1c63862e8858694ce3b83f5d372ad789@proxima.alt.za> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1c63862e8858694ce3b83f5d372ad789@proxima.alt.za> Topicbox-Message-UUID: 533eea0a-ead0-11e9-9d60-3106f5b1d025 > Would it be out of the question to add an option to Fossil that > constructs users on the fly? Or perhaps the type of utility used on > sources to create new users, but limited to entries authenticated from > a /lib/ndb/auth-listed authentication source? Something that is done > preliminary to establishing a CPU connection so it is executed in an > authoritative namespace and with sensible defaults? Creating users on the fly would probably be fine for cases like these. There is still a translation table from unames to disk uids so that if there's a user "boyd" and he leaves and someone else comes along and wants to be user "boyd", we can assign the new user "boyd" a different disk uid (like "boyd2") so that we can reuse the uname "boyd" but new boyd can't read old boyd's files from the dump. For something like a 9grid, maybe you're willing to give that up in order to avoid creating accounts explicitly. It's not much code, it would be contained in /sys/src/cmd/fossil/9user.c, but you'd have to fiddle a little with the locking, probably vtRUnlock inside _userByUname, vtLock, create the new user, vtUnlock, and then vtRLock again. Probably pull out the cmdUname user create code into its own function so that you can reuse it. Russ P.S. The type of utility used on sources is not much more than two tin cans and a piece of string.