From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Mon, 20 Oct 2008 22:29:17 -0500 From: "Eric Van Hensbergen" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: <476c0463b6a73667d50ba792ef1ada3d@quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <476c0463b6a73667d50ba792ef1ada3d@quanstro.net> Subject: Re: [9fans] Multi-domain authentication? Topicbox-Message-UUID: 234cc124-ead4-11e9-9d60-3106f5b1d025 On Mon, Oct 20, 2008 at 7:49 PM, erik quanstrom wrote: > > the premise is that the local system, and thus i assume the local fs, has > no knowledge of the user. this task has been delegated to a foreign auth > server. so what are the mechanics of getting the local fs to treat an > unknown user as something other than none? > Good general problem, I'd also like to add my personal pain point that only the file server knows about the relationship between groups and users. It'd be nice to have a more general service to take care of this, and include some ability to assign remote delegated user names to local groups. I also like the idea of having "user-context" groups where users can create their own groups and assign local and remote users to them for the purposes of accessing file servers they "own". > > supposing this problem is solved, don't you need quotas or something > if you don't know who exactly to yell at for filling up the worm? > There are lots of different solutions here -- could be as simple as only using ramfs or ramdisk, could just require the user to use /mnt/term as his space, or be nice and provide cfs style semantics on top of /mnt/term to make it a bit snappier. In any case, I don't see any of this as a major barrier to the desire for multi-domain authentication. -eric