Date: Mon, 12 Feb 2001 11:39:33 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: freebsd-audit@freebsd.org, dillon@freebsd.org Cc: Thomas Moestl <tmoestl@gmx.net> Subject: Re: patch to remove setgid kmem from top Message-ID: <Pine.NEB.3.96L.1010212113547.88322D-100000@fledge.watson.org> In-Reply-To: <20010202015844.A1246@crow.dom2ip.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Other than Kris's comment regarding lastpid/nextpid semantics, I was wondering if there were any further reviews based on the diffs for these changes themselves. If not, I'd like to go ahead and commit them. In particular here, I'm looking for a review and final OK of the swap-related changes from Matt, since I have approximating zero vm-clue, and whether anyone knows anything about the current contrib status of the top command -- is it externally maintained, is it OK to commit to it and possibly pull things off a vendor branch, if any? I'm going to go ahead and commit the SYSCTL addition of exporting lastpid now, as that seems fine to me :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Fri, 2 Feb 2001, Thomas Moestl wrote: > Hi, > > I have prepared a set of patches that allow running top as an ordinary > user without setgid kmem. > > As this is somehow security related (and because I would like this > patches to be reviewed), I'm posting to -audit. Please give me a > pointer if you feel that this is the wrong forum. > > All information top needs is now read via the sysctl interface. > > One sysctl, kern.lastpid, had to be added for this. It exports the > nextpid variable, which reflects the highest PID used up to now. > This information was given away before by top. It could allow > discovering a PID before the corresponding process is run for the > first time (but after the fork call started when randompid is enabled). > I don't think that this is a security issue (there are other ways to > discover PIDs after all, unless with restrict e.g. ps). > > Another thing that needed to be changed is the libkvm kvm_getswapinfo() > call that made heavy use of kvm_read. I have changed the kernel to > do per swap area accounting (as discussed on -hackers), and have > exported this information via the vm.nswapdev sysctl (number of swap > areas) and the vm.swapdevX nodes (where X is the device), which > contain the MIBs dev, nblks, used and flags. > > A patch to libkvm makes use of these new sysctls in the case of "live" > kernels, and changes the dump case so that the information gathered > in the kernel is used instead of walking the radix tree. A side effect > of this change is that kvm_getswapinfo() is faster now in the general > case. If the SWIF_DUMP_TREE flag is given (pstat -ss does this), the > radix tree walker, which still uses kvm_read in any case, is invoked, > but I don't think that this information needs to be exported for > ordinary users. > > The changes are split into three diffs: > - for top: http://www.tu-bs.de/~y0015675/top.diff > - for libkvm: http://www.tu-bs.de/~y0015675/libkvm.diff > - for the kernel: http://www.tu-bs.de/~y0015675/sysctl.diff > (I don't want to post the patch files if not necessary, they are a bit > large for that). > > Could someone please review these patches, and if they are OK, commit > them? > > Thanks, > - thomas > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-audit" in the body of the message > 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.1010212113547.88322D-100000>