Garrett D'Amore wrote: > Craig Mohrman wrote: >> 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. > > Excellent! Does it use exclusively public /proc interfaces? Any that > are not public will still need to be documented/contracted. >
A quick read of the source and it appears to use only standard interfaces. If I discover any non-standard interfaces I will prepare contracts for any private interfaces before integrating the packages. craig >> >> And the top binary does NOT have any special set(gu)id privileges. > > That is goodness as well. I guess top has improved quite a bit since > last I looked at it. (Admittedly, it had been a while.) > > -- Garrett >
