From owner-freebsd-hackers Thu Oct 7 19: 6:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 6F8AA153AB; Thu, 7 Oct 1999 19:06:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 65C451CD43A; Thu, 7 Oct 1999 19:06:45 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Thu, 7 Oct 1999 19:06:45 -0700 (PDT) From: Kris Kennaway To: Pat Dirks Cc: FreeBSD Hackers Subject: Re: Apple's planned appoach to permissions on movable filesystems In-Reply-To: <199910052119.OAA24627@scv1.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here's a passing thought I had which may be relevant. Make uids randomly assigned. This solves the problem of collision between uids on an introduced medium and the ones on the local system by making it statistical (if the uid space is large enough). In order to manage this among multiple machines, you'd probably need a synchronisation facility, both online (connect to some network database), and by an "export/import" facility which lets you dump a DB and import (parts of) it on another machine. Storing the large uid in the inode is probably not feasible w/o breaking compatability, but you could indirect it through a mapping table loaded from elsewhere on disk when the FS is mounted. The downside to this is not being able to assign the uids according to your own numbering scheme. Perhaps what could be done is to have a lookup table which maps between in-system uids and on-disk ones, such that the kernel presents the translated uid to the system, and remaps the unknown ones. Kris ---- XOR for AES -- join the campaign! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message