Garrett D'Amore wrote: > Nicolas Williams wrote: >> On Wed, Aug 20, 2008 at 01:11:27PM -0400, James Carlson wrote: >> >>> Darren J Moffat writes: >>> >>>> Given all the above this case should be marked as withdrawn sine >>>> nothing in the case is valid for the new proposal. A new case for >>>> delivering top should be started. >>>> >>> What would be the point of that? I think reusing the same case (and >>> providing a more up-to-date synopsis) would be the better answer. >>> >> >> It's probably useful, though marginally so, to look at case summaries >> and see that "prstat utility enhancements to look and act more like top" >> was withdrawn and shortly after a case was submitted and approved for >> "top for OpenSolaris." Is that sufficiently useful to warrant >> withdrawing and >> submitting a new case? >> >> Dunno, but if not the IAM does need to be updated so the case shows up >> as "top for OpenSolaris" instead of "prstat utility enhancements to look >> and act more like top." >> >> Nico >> > Okay, so while providing (shipping) unix top seems at first blush not > a bad idea, there is one significant hiccup. FOSS top (the last time > I looked) grunges around in kmem, making use of uncommitted and > undocumented APIs, structures, etc.. (Possibly this has changed, but > I sort of doubt it.) > > So, *particularly* given its distribution in another consolidation, I > think the project team needs to either: > > a) document and get contracts for any non-public APIs, structures, or > such that it uses > > or > > b) convert the backend data collection in top to use > documented/stable/committed APIs (/proc, dtrace, or whatever.) > > Just "shipping" top is probably not (IMO) less work than enhancing > prstat; its certainly not a simple slam dunk as some on this list have > asserted. > > Another significant thing that must be documented with top is any > security implications. I believe top is normally installed sgid or > suid so it can access /dev/kmem. There are also issues with some of > the actions it can perform (killing, renicing processes) -- how, if at > all, are such actions audited, etc. (Does top yield privileges after > attaching to kmem? There might also be concerns about interaction > with least privilege awareness -- I've not studied this problem enough > to know for sure.) While its likely that on a single user desktop > these considerations are not important, the situation is very > different in a multi-user (possibly multi-zone) enterprise environment. >
To address the /dev/kmem groveling this version of top does NOT access /dev/kmem. It uses /proc. And the top binary does NOT have any special set(gu)id privileges. craig
