[EMAIL PROTECTED] writes:
>
> Pavel Roskin, [EMAIL PROTECTED], replies:
>
> > I believe this was a quick fix to close a security hole. Instead of
> > checking that the target directory is still under the allowed root, CVS
> > just forbids using ".." for some (not fot all) commands.
>
> Larry Jones, [EMAIL PROTECTED] replies:
>
> > I think this is a bug -- the client is supposed to tell the server how many
> > levels of .. it expects to send and the server compensates, but when the
> > code was rearranged to support multiple repositories the code to send
> > the information was moved so that it happens too late in the process.
>
> Ok, which is it? :) Bug or quick fix to a security problem?
Bug. The client/server protocol has a Max-dotdot request that sets the
number of directory levels above the current directory that are needed.
The server creates a nest of that many dummy directories and cd's to the
bottom; that way, any file name with no more than the requested number
of ..'s will still be within the server's temp directory tree. When the
server gets a file or directory name, it checks it against the client's
declared Max-dotdot and issues a protocol error if it exceeds it. The
c/s protocol requires Max-dotdot to be sent before the first Directory
request but, due to the above-mentioned code rearrangement, it gets sent
afterwards, so any Directory request with .. gets rejected.
> Larry Jones, [EMAIL PROTECTED] continues:
>
> > > If I pass the full pathname of the file (e.g.,
> > > "$HOME/cvs/foo/include/foo.h"), I get
> > > absolute pathname '/home/hal/cvs/foo/include' illegal for server
> >
> > This is intentional.
>
> Was there some security problem associated with it? Do you recall the
> details? Just a curiosity...
That was a quick fix to a security problem. :-) Some selected comments
from server_pathname_check():
/* An absolute pathname is almost surely a path on the *client* machine,
and is unlikely to do us any good here. It also is probably capable
of being a security hole in the anonymous readonly case. */
/* Giving an error is actually kind of a cop-out, in the sense
that it would be nice for "cvs co -d /foo/bar/baz" to work.
A quick fix in the server would be requiring Max-dotdot of
at least one if pathnames are absolute, and then putting
/abs/foo/bar/baz in the temp dir beside the /d/d/d stuff.
A cleaner fix in the server might be to decouple the
pathnames we pass back to the client from pathnames in our
temp directory (this would also probably remove the need
for Max-dotdot). A fix in the client would have the client
turn it into "cd /foo/bar; cvs co -d baz" (more or less).
This probably has some problems with pathnames which appear
in messages. */
-Larry Jones
I don't NEED to compromise my principles, because they don't have
the slightest bearing on what happens to me anyway. -- Calvin
