[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
vi lack of permission error handling.
- To: bugs_(_at_)_openbsd_(_dot_)_org
- Subject: vi lack of permission error handling.
- From: Xyntrix <xyntrix_(_at_)_bitz_(_dot_)_org>
- Date: Tue, 5 Jun 2001 15:23:42 -0700
this shouldn't typically happen in a real world environment, but i seem to have
found a bug in the way vi under openbsd x86 2.8-2.9 handles the inability to
read a temp file created in /tmp when trying to edit a new file.
if one sets their umask so that the default user permissions exclude the read
access bit: vi will fill /tmp with temp files, be unable to abort via ^C or ^D,
and increase it's cpu usage to %99 under default system configurations that
don't limit users' cpu usage.
typically there isn't really a reason to set a umask to non-read for the
user's permissions, but there should be a better way of vi to handle such a
circumstance.
example:
version from :ve command within vi,
Version 1.79 (10/23/96) The CSRG, University of California, Berkeley.
[hathor] (xyntrix): uname -a
OpenBSD hathor 2.9 GENERIC#653 i386
[hathor] (xyntrix): ls -la `which vi`
-r-xr-xr-x 3 root bin 278528 Apr 28 12:19 /usr/bin/vi
[hathor] (xyntrix): umask
022
(/home/xyntrix)
[hathor] (xyntrix): umask 722
(/home/xyntrix)
[hathor] (xyntrix): vi foo
^C^C
^D^D
^Z
[1]+ Stopped vi foo
[: another console :]
[hathor] (xyntrix): ps auwx|head -1;ps auwx|grep "vi foo"|grep -v grep
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
xyntrix 29524 93.9 1.3 1968 2548 p5 R+ 3:05PM 0:46.10 vi foo
this same scenario under solaris 7/8 gives a "permission denied" error.
__________________
xyntrix_(_at_)_bitz_(_dot_)_org |
~~~~~~~~~~~~~~~~~~
Visit your host, monkey.org