[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

vi lack of permission error handling.



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