Date: Wed, 21 Mar 2001 23:10:45 -0500 From: Sergey Babkin <babkin@bellatlantic.net> To: Terry Lambert <tlambert@primenet.com> Cc: fs@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: about common group & user ID space (PR kern/14584) Message-ID: <3AB97B45.37E4957F@bellatlantic.net> References: <200103200521.WAA23451@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > > > > You could do this a bit more cleanly by just stealing the sign > > > bit, and setting if the uid field contained a group ID. > > > > > 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. It is expected that the people would bring their whole u/gid/namespace (or at least its portion described by the sysctls as common space) into the required consistent form before enabling this feature. This is why I don't want this feature enabled by default. I plan to implement it over NFS as well but if the NFS server does not support this feature, then yes, the ownership will be given to the pseudo-user with ID coinciding withthe group ID only (and if the namespace is consistent then such a pseudouser with the same name and id as the group must exist). > 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. No, I don't. The origin of the passwd/group files is irrelevant. Only their contents is important. And yes, if someone is using NIS, their choice would be to either set the commonalized portion of the ID space as local or make the ids/names unique in the NIS maps. Or, of course, not enable this feature. > 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". Yes, the common id range is tuned by sysctl. > 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. That's why I consider the uniqueness rule so important in the distribution of uids/gids/names: - each user ang group must have a different name in the common namespace - each user ang group must have a different id in the common id space - for each group there must be a pseudo-user with the same ID and name and because by historical compatibility reasons applying these requirements to the whole id space is impossible, only part of the id space is enabled as compliant. > > > 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... Hm, probably yes, they can be put into a loop. > > 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 > > 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. The passwd/group files do not enforce it either. So it's just a convention to which the sysadmins should comply. If they can't comply they must not enable this feature. > 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. Wihtout the stolen bit it works on the remote machine as well, and even names will be shown properly because NFS implies the same users/groups on both machines. Just the permissions on the remote machines will be more restrictive. > 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. Well, the standard permissions scheme and especially NFS has this sort of agreement as well. Nothing stops an NFS client from assigning the IDs and names completely differently than on the server. Or another typical breakage is when an user in not listed in /etc/group for his primary group. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AB97B45.37E4957F>