Re: Assumption added between 1.11.9 and 1.11.16 ?

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Adrian,

My recollection is that the change you are mentioned was added to
deal with symlinks in the cvsroot path. I believe you will find
the root of the thread that discussed here:

    http://lists.gnu.org/archive/html/bug-cvs/2003-09/msg00168.html

If you have a 'better' solution than the current use of xgetwd(), please
feel free to forward a patch. I doubt it will be fixed without one as
most folks apparently do not run their repositories with the same
permissions you are using.

That said, I have not considered the logic path closely recently, but
you may want to consider the use of CVSROOT/config using a
LockDir=/path/name to see if that will help you. You could give
different permissions to the LockDir than the normal repository and may
find more joy in it.

        -- Mark

PS: It is "Labor Day" today in the US, don't assume anyone in the US
will be doing much e-mail...

Adrian Pepper <arpepper@cs.uwaterloo.ca> writes:

> > 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFBPBL53x41pRYZE/gRAgcbAJ4p+R73e1TVluB9RprLHi/75ztnrACgtCTE
kdwhcYEjb7hTl+RIYjgUMPM=
=yQfb
-----END PGP SIGNATURE-----