Date: Tue, 20 Mar 2001 05:20:59 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: babkin@bellatlantic.net (Sergey Babkin) Cc: fs@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: about common group & user ID space (PR kern/14584) Message-ID: <200103200521.WAA23451@usr05.primenet.com> In-Reply-To: <3AB6AA65.1B6ED19E@bellatlantic.net> from "Sergey Babkin" at Mar 19, 2001 07:55:01 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103200521.WAA23451>