From owner-freebsd-arch Mon Mar 19 21:21:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 9A72737B731; Mon, 19 Mar 2001 21:21:33 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id WAA14447; Mon, 19 Mar 2001 22:14:43 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAAgvai7B; Mon Mar 19 22:14:28 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id WAA23451; Mon, 19 Mar 2001 22:21:04 -0700 (MST) From: Terry Lambert Message-Id: <200103200521.WAA23451@usr05.primenet.com> Subject: Re: about common group & user ID space (PR kern/14584) To: babkin@bellatlantic.net (Sergey Babkin) Date: Tue, 20 Mar 2001 05:20:59 +0000 (GMT) Cc: fs@FreeBSD.ORG, arch@FreeBSD.ORG In-Reply-To: <3AB6AA65.1B6ED19E@bellatlantic.net> from "Sergey Babkin" at Mar 19, 2001 07:55:01 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > You could do this a bit more cleanly by just stealing the sign > > bit, and setting if the uid field contained a group ID. > > > > There would be no conversion problem for an existing system. > > That was my original idea but some thinking and experimentation > has shown that it creates too many incompatibilities, such as: > > - programs displaying the owner by name would break, and > that includes both the standard programs and random applications > - when exported by nfs, the same problem would stand for the > clients > - chown will have to be changed - both the program and system call, > as you mention later > > and possibly other sorts of breakages. The NFS breakage is going to be there in any case; the semantics will be different on the remote machine, giving ownership to a particular user (who doesn't exist). This will turn "owner by name" numeric at best, and give ownership to a particular person, not group, at worst. You also have the problem that the FreeBSD machine has to be your NIS master; in a heterogeneous environment, Sun boxes are still better NIS servers, since they understand the full complement of NIS maps, which FreeBSD doesn't, and they support automount (as opposed to amd, which happily requires a reboot to unwedge in many situations). Any time you internalize or externalize a uid/gid space, you will have that problem. Plus, with your approach, you are either going to have to make an exception for certain ID ranges, permitting overlap, or you are going to be stuck renumbering things like "bin" and "kmem". Further, even if the FreeBSD was the NIS master for NFS name interpretation, the only safe way to make the maps transportable would be to have identical group and password name/ID pairs. This breaks for normal duplication, which exists now: you can't have two entries in either file for the same key field, since a getpwuid or getgrgid will only return the first matching value in all cases. > > This changes the check to a one line change, conditional on > > the high bit being set. > > No, the change would be the same, just wrapped into a condition > check for this bit. I think you could "fudge" the in core copy of one id to be the other, with the bit OR'ed in or AND'ed off, as appropriate... > In the way I propose it, the sysadmins are supposed to create > a pseudo-user with the same name and ID as each group. That > automagically makes all commands, such as chown and ls, work > properly. Of course, that means that no real users and groups > must have the same name, but the common namespace looks natural > with the common ID space. Because the traditional users ang groups > with low IDs do have overlapping names, and IDs, the sysctl sets > the lowest ID from which the common ID space starts. If the sysctl > sets this value to below 100 (traditional range for the > system IDs), then the common ID code is disabled altogether. > The value of 100 is set by a kernel config option and may be changed. This explodes when your remote NIS server doesn't enforce the new semantics; this is sort of the opposite of the problem I cite above with not being able to maintain a single namespace. Really, the namespace and the ID space are paired, so the only practical thing to do is to seperate the ID space and the namespace at the same time. I really think it's a lot easier to do this by stealing a bit somewhere (second one down from the sign, if the sign is to be held sacrosanct) than it is to rely on semantic enforcement by your tools. As soon as you do that, it becomes significantly less useful. At least with a stolen bit, the ownership on the remote machine works, even if it doesn't precisely "make sense" the same way it does on the hacked FreeBSD box. > > The benefits in not having the grovel through the FS contents, or > > do a more complex ID space transformations, and the moving of the > > majority of changes to user space, combined with the fact that if > > you turn it off, the ownership doesn't need to be reverted, are > > all plusses. > > This is not quite so. My patch requires only one little change in > the kernel and no usel-level space changes at all. It has some > expectations for the assignment of user and group IDs and names, > but these expectations are justified to make the common ID space > look reasonable. The downside is that it's slightly slower > (for each file owner ID in the common space it has to be checked > agains all process'es groups). I'm not sure yet if it allows > more complex transformations and whether it does it comparable > to your proposal. You could do the transformations with a mapping layer (left as an exercise for the student), but it would not really be worth it, I think. The biggest problem is that the tools have to have a gentleman's agreement between themselves across systems that everyone will sign up to honor. That's really too kludgy to trust, unless you are in a homogeneous environment (if then). Placing this as a restriction makes the idea much, much less generally useful than it would otherwise be. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message