[9896] in Athena Bugs
decmips 7.4G: red(1)
daemon@ATHENA.MIT.EDU (Calvin Clark)
Thu Sep 17 13:45:13 1992
Date: Thu, 17 Sep 92 12:50:05 -0400
From: Calvin Clark <ckclark@mit.edu>
To: bugs@Athena.MIT.EDU
Reply-To: ckclark@mit.edu
System name: podge
Type and version: KN01 7.4G
Display type: PMAX-MFB
What were you trying to do?
Use the restricted editor "red" to edit a file in the current
directory.
What's wrong:
One of the restrictions on this version of is is that it "only
lets you edit files in the current directory" (the other is that you
can't use ! to invoke a shell command.) However, its method of
determining whether or not a file is in the current directory is a bit
rudimentary. The algorithm seems to be: if the filename contains a '/',
then it's in the current directory, otherwise it's not:
# 54 <ckclark@podge> Thu Sep 17 12:22:25 /tmp
; red
e ./foo
?
e foo
2538
e /tmp/foo
?
q
Okay, I'll admit that if I try to use relative or absolute paths
to specify a filename in an editor that only works on files in the
current directory, than I'm probably a bit of a dork.
However, because of this braindead scheme, it is indeed possible
to use the restricted editor to edit files in other directories, if
symlinks in the current directory exist. Whether or not this is
security hole is a matter of opinion, but this behavior should at least
be made clear in the man page, so that people who might want to set up
something secure will be forewarned about this possibility. Usually, in
some setup where red might be used, the only shell access would be
through a restricted shell like rsh5 (rksh, described in the ksh(1) man
page, is not installed), so the user would probably not be able to
invoke ln to create the symlinks anyway.
What should have happened:
It is probably okay to leave the code as is, but document it
better.
Please describe any relevant documentation references:
ed(1)
