From owner-freebsd-arch Mon Mar 19 16:57: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 8642637B71E; Mon, 19 Mar 2001 16:56:34 -0800 (PST) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-151-198-135-36.nnj.dialup.bellatlantic.net [151.198.135.36]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id TAA23200; Mon, 19 Mar 2001 19:55:05 -0500 (EST) Message-ID: <3AB6AA65.1B6ED19E@bellatlantic.net> Date: Mon, 19 Mar 2001 19:55:01 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Terry Lambert Cc: security@FreeBSD.ORG, Wes Peters , Robert Watson , fs@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: about common group & user ID space (PR kern/14584) References: <200103180738.AAA03250@usr05.primenet.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > I want to commit PR kern/14584. I've been told that it's good > > to discuss it in -arch, -security and -fs. (It has been sort of > > discussed on -hackers already, there were not much replies). > > So I've posted a message on -arch, and now on -security and -fs. > > I've also discussed this idea shortly with Kirk McKusick at > > Usenix-2000 at the BSD BOF and he generally liked it and suggested > > to review further. > > 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. > 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. > Note that this change is really necessary in the user space code > anyway: even if you make the UID and GID numeric values not > intersect, there is still the possibility of a group and user > having the same name, so a set-by-name needs a seperate flag > (thing "chown bin.bin foo", for example). 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. > 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. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message