Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Mar 2001 19:55:01 -0500
From:      Sergey Babkin <babkin@bellatlantic.net>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        security@FreeBSD.ORG, Wes Peters <wes@softweyr.com>, Robert Watson <rwatson@FreeBSD.ORG>, fs@FreeBSD.ORG, arch@FreeBSD.ORG
Subject:   Re: about common group & user ID space (PR kern/14584)
Message-ID:  <3AB6AA65.1B6ED19E@bellatlantic.net>
References:  <200103180738.AAA03250@usr05.primenet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AB6AA65.1B6ED19E>