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>