svn commit: r334543 - head/usr.bin/top

[Don Lewis]

On  2 Jun, Rodney W. Grimes wrote:
>> Author: eadler
>> Date: Sat Jun  2 22:06:27 2018
>> New Revision: 334543
>> URL: https://svnweb.freebsd.org/changeset/base/334543
>> 
>> Log:
>>   top(1): chdir to / as init; remove unneeded comment
>>   
>>   - chdir to / to allow unmounting of wd
>>   - remove warning about running top(1) as setuid. If this is a concern we
>>   should just drop privs instead.
>> 
>> Modified:
>>   head/usr.bin/top/machine.c
>>   head/usr.bin/top/top.c
>> 
>> Modified: head/usr.bin/top/machine.c
>> ==============================================================================
>> --- head/usr.bin/top/machine.c	Sat Jun  2 21:50:00 2018	(r334542)
>> +++ head/usr.bin/top/machine.c	Sat Jun  2 22:06:27 2018	(r334543)
>> @@ -1613,11 +1613,6 @@ compare_ivcsw(const void *arg1, const void *arg2)
>>  /*
>>   * proc_owner(pid) - returns the uid that owns process "pid", or -1 if
>>   *		the process does not exist.
>> - *		It is EXTREMELY IMPORTANT that this function work correctly.
>> - *		If top runs setuid root (as in SVR4), then this function
>> - *		is the only thing that stands in the way of a serious
>> - *		security problem.  It validates requests for the "kill"
>> - *		and "renice" commands.
>>   */
>>  
>>  int
>> 
>> Modified: head/usr.bin/top/top.c
>> ==============================================================================
>> --- head/usr.bin/top/top.c	Sat Jun  2 21:50:00 2018	(r334542)
>> +++ head/usr.bin/top/top.c	Sat Jun  2 22:06:27 2018	(r334543)
>> @@ -260,6 +260,15 @@ main(int argc, char *argv[])
>>  #define CMD_order	26
>>  #define CMD_pid		27
>>  
>> +    /*
>> +     * Since top(1) is often long running and
>> +     * doesn't typically care about where its running from
>> +     * chdir to the root to allow unmounting of its
>> +     * originall wd. Failure is alright as this is
>> +     * just a courtesy for users.
>> +     */
>> +    chdir("/");
>> +
> 
> Bad side effect of doing that is it is not hard to get a "core"
> from top when run as a user, as it is going to try to write
> to /, and it probably does not have permission for that.
> 
> Better might be a cd to /tmp, or /var/tmp, which are usually
> hard to unmount for these reasons anyway.

Unless you start top using the exec shell builtin, the shell that you
use to launch top will also be long running and will also prevent its
$cwd from being unmounted.

If you do use exec, then you will get logged out when you kill top ...