From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Tue, 29 Jan 2008 15:58:32 +0000 From: "roger peppe" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] the meaning of group In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Topicbox-Message-UUID: 3c7fa248-ead3-11e9-9d60-3106f5b1d025 > the problem is that this information needs to be updated across all cpu servers > more often than everything is rebooted. it seems to me that if this was a real requirement, and you wish group coordination across several machines, that you could add a kernel service, say #G, which would provide a file, say "groupquery", that some trusted process could read, in the style of factotum's needkey, to answer group requests for the kernel. inside the kernel, perhaps you'd provide call "ingroup(user, group)" to query whether a particular user was a member of a particular group - it would block until the request was answered, or return false if no process has opened the file. to speed things up, you could implement a simple leasing system which would allow ingroup() to cache answers for a while rather than going to user space each time. once you've got this primitive, you could link it to whatever you liked, for instance a fileserver instance, or a protocol mediated by factotum.