Date: Fri, 2 Feb 2001 19:27:13 +0200 From: Peter Pentchev <roam@orbitel.bg> To: Robert Watson <rwatson@freebsd.org> Cc: Thomas Moestl <tmoestl@gmx.net>, freebsd-audit@freebsd.org Subject: Re: patch to remove setgid kmem from top Message-ID: <20010202192712.Y328@ringworld.oblivion.bg> In-Reply-To: <Pine.NEB.3.96L.1010202121528.30423C-100000@fledge.watson.org>; from rwatson@freebsd.org on Fri, Feb 02, 2001 at 12:21:08PM -0500 References: <20010202191201.X328@ringworld.oblivion.bg> <Pine.NEB.3.96L.1010202121528.30423C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 02, 2001 at 12:21:08PM -0500, Robert Watson wrote: > > 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. I'm aware of all this; I just meant that IF the tools are changed to use sysctl() on the running kernel and libkvm or direct mapping or whatever they're using now on crash dumps, THEN the tools need no longer be setgid. Being setgid has nothing to do with the ability to work on a crashdump, it's all about libkvm access to the running kernel. True, the two are interrelated, inasmuch as if a tool is not setgid anymore, this *most probably* means it only uses sysctl's and cannot work on a crashdump - it does not *necessarily* mean that, though; with special case handling, a non-setgid tool can work on a crash dump just as well :) OK, OK, I'll shut up now - yes, we are saying mostly the same things, and yes, I just had to state my point of view on those very same things once again :) G'luck, Peter -- I am the meaning of this sentence. 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?20010202192712.Y328>