Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 2 Feb 2001 12:21:08 -0500 (EST)
From:      Robert Watson <rwatson@freebsd.org>
To:        Peter Pentchev <roam@orbitel.bg>
Cc:        Thomas Moestl <tmoestl@gmx.net>, freebsd-audit@freebsd.org
Subject:   Re: patch to remove setgid kmem from top
Message-ID:  <Pine.NEB.3.96L.1010202121528.30423C-100000@fledge.watson.org>
In-Reply-To: <20010202191201.X328@ringworld.oblivion.bg>

next in thread | previous in thread | raw e-mail | index | archive | help

On Fri, 2 Feb 2001, Peter Pentchev wrote:

> On Fri, Feb 02, 2001 at 12:04:44PM -0500, Robert Watson wrote:
> > 
> > This is great -- I won't have a chance to look in detail at your patches
> > for a bit, but it seems that this is a great step forwards.  I don't
> > suppose you want to now turn your interest to netstat, vmstat, iostat,
> > dmesg, nfsstat, pstat, and systat? :-)  Much of the information needed in
> > many of these is already exported -- in my mind systat is the most
> > important as it links against ncurses and provides an interactive
> > interface.  Also, systat is least likely to suffer from the "but it won't
> > work on a kernel dump" syndrome as it is generally not used for a post
> > mortem.
> 
> Actually, working on a kernel dump has absolutely nothing to do with
> suid/sgid-ness, IMHO..  I might be terribly wrong here, but doesn't
> sgidness come because the utilities must examine the core kernel memory
> - which is all in the dump file?  If working on a dump, do *stat really
> need access to the memory/symbols of the *running* kernel? 

There are two reasons why the current kmem interface for retrieving kernel
configuration/statistics is used:

1) Necessary information is not exported using sysctl, ioctl, or other
   management interfaces.

2) Using the kmem interface allows the same programs to be applied to
   kernel dumps to allow post-mortem analysis in the same way they work on
   the live kernel when pointed to /dev/kmem.  This is a bit like being
   able to point gdb at both a dump and /dev/mem.  This allows no special
   case coding to handle one or the other.

As tools are migrated to using sysctl() for information retrieval,
allowing the setgid kmem bit to be removed, we've found resistance if the
tools then lose the ability to be used on dumps for post-mortem.  For
example, vmstat -m and netstat are both very useful tools for
understanding the condition of a kernel at the moment it panicked.  The
tricky bit is not so much in moving to sysctl(), but allowing the tool to
still work on both of them without lots of special-case coding.  This is
why ps and other tools continue to use the kmem process information
interface, even though in practice they don't use kmem, rather sysctl, to
retrieve the information.  It's ugly, but it's not clear what the right
solution is.  This use of the same structures for management and internal
use in the kernel has caused breakage elsewhere, and is one reason why
Kirk recently committed code to distinguish the in-kernel proc structure
and one used outside the kernel, so that changes in the in-kernel
structure don't break all the management tools.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org      NAI Labs, Safeport Network Services





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-audit" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010202121528.30423C-100000>