Re: Assumption added between 1.11.9 and 1.11.16 ?

[Adrian Pepper]

> From bug-cvs-bounces+arpepper=math.uwaterloo.ca@gnu.org Fri Sep  3 11:39:09 
> 2004
> Date: Fri, 3 Sep 2004 11:38:34 -0400 (EDT)
> From: Adrian Pepper <arpepper@cs.uwaterloo.ca>
> To: bug-cvs@gnu.org
> Subject: Re:  Assumption added between 1.11.9 and 1.11.16 ?
> 
> > From bug-cvs@gnu.org Fri Sep  3 11:35:20 2004
> > Date: Fri, 3 Sep 2004 11:34:37 -0400 (EDT)
> > From: Adrian Pepper <arpepper@cs.uwaterloo.ca>
> > To: bug-cvs@gnu.org
> > Subject: Assumption added between 1.11.9 and 1.11.16 ?
> > 
> > From a course instructor:
> > 
> > | The error is
> > |
> > | rees ~: cvs co nachos
> > | cvs [checkout aborted]: cannot getwd in /u/XXXXXXXXX/.newcvsroot/cvsroot:
> > | Permission denied
> > 
> > 
> > Because of security warnings, I upgraded from 1.11.9 to 1.11.16
> 
> P.S. I looked briefly at the web release notes and didn't find anything
> indicating restriction was added  (or removed in 1.11.17 -- some day...)

Sorry I was busy doing something I had never done before, and sent the
report off in haste, hoping it would instantly twig someone's
recognition of the change they had helped with.

Architecture is Solaris, primarily 8 (2.8/SunOS5.8)
E.g. (but not exclusively)
SunOS cscf.cs 5.8 Generic_117350-05 sun4u sparc SUNW,Ultra-5_10
We use an NFS fileserver which prevents the use of ACLs.
We compile using a fairly up-to-date gcc.  (3.3.4 du jour)

A "diff -r" of cvs-1.11.9 and 1.11.16 does indicate that several
extra calls to "xgetwd" were added.  (Suggestion: don't use
the name "getwd" in your error messages--that's the old deprecated
routine with unavoidable buffer overflow problem).

This diagnostic from xresolvepath is, I believe, the one which users
ran into when trying to do anything with a repository in a path
which was entirely searchable but not readable.

     if ( ( hardpath = xgetwd() ) == NULL )
       error (1, errno, "cannot getwd in %s", path);


Examination of cvs-1.11.9 shows that the xgetwd() routine was
already present in that version.

Which rather suggests that, unless all uses of the routine had
contingency plans (at times, would only the portions of the path
up-to/down-from the cvs root be useful?) some, but not all uses of cvs
might previously have run afoul of xgetwd checks.  Can anyone
confirm that?  In what cases would xgetwd have been called?  Would
it have caused a failure, or merely a warning?

I am preparing versions of 1.11.9, 1.11.16 and 1.11.17 for comparative
testing (preparing now, for testing on Tuesday or Wednesday).

Could someone please respond indicating that they understand the
problem, and give me some idea of the probability of it being
fixed (okay, so there's a slim chance you fixed it without much
comment in 1.11.17, although I expect someone would have told me
that already if you had).  Alternatively can you give me strong
ammunition to defend the idea that cvs should not be useable on
repositories whose roots are in directories searchable but unreadable
by the user.  Examples of what people wish to accomplish through the
use of symlinks (as far as I can tell, that's what lots of the
recent additional uses of xgetwd where trying to improve), and an
indication of why it is necessary to resolve the entire path
up to the filesystem root would be useful.

A clever getcwd, given a guess as to the identity of the unreadable
directory ($PWD), can work up from the directory above it, and up
towards it, confirming the identity of the unreadable directory by
inode number, and generate a complete absolute path that way.
Alternatively, cvs might be able to work with the portion of the paths
beneath the repository only.

Is there some slim chance a change in the behaviour of Sun's getcwd
routine caused the problem?


Adrian Pepper
Computer Science Computing Facility
University of Waterloo, Waterloo, Ontario, Canada
arpepper@cs.uwaterloo.ca