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.
>
> 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
