Hello,
the reason for the reported problems of WinCVS and directory
based access control has been found. Since CVS is a normal
no-suid program, no Linux file protecions were circumvented
at any time.
The problem results from the interpretation of the CVS/Root
files. The contain a single line "user@remote:/data/cvshome".
>From within Linux it is no problem to checkout as "user1" and
to commit as "user2" and vice versa, except for the wanted
forbidden commit for "user2":
With a previous checkout into a directory of "user1":
cvs -d ":ext:user1@remote:/data/cvshome" LibSub.htm
user1@remote's password:
Checking in LibSub.htm;
/data/cvshome/GP/LibSub/LibSub.htm,v <-- LibSub.htm
new revision: 1.22; previous revision: 1.21
done
cvs -d ":ext:user2@remote:/data/cvshome" LibSub.htm
user2@remote's password:
Checking in LibSub.htm;
/data/cvshome/GP/LibSub/LibSub.htm,v <-- LibSub.htm
new revision: 1.23; previous revision: 1.22
cvs [server aborted]: could not open lock file
`/data/cvshome/GP/LibSub/,LibSub.htm,': Permission denied�
With a previous checkout into a directory of "user2":
cvs -d ":ext:user2@remote:/data/cvshome" LibSub.htm
user2@remote's password:
Checking in LibSub.htm;
/data/cvshome/GP/LibSub/LibSub.htm,v <-- LibSub.htm
new revision: 1.23; previous revision: 1.22
cvs [server aborted]: could not open lock file
`/data/cvshome/GP/LibSub/,LibSub.htm,': Permission denied
cvs -d ":ext:user1@remote:/data/cvshome" LibSub.htm
user1@remote's password:
Checking in LibSub.htm;
/data/cvshome/GP/LibSub/LibSub.htm,v <-- LibSub.htm
new revision: 1.23; previous revision: 1.22
done
However WinCVS uses the contents of CVS/Root for further
accesses of the repository after a checkout. Changing
the proper CVS/Root file "helps", even with an active
WinCVS.
Regards,
Martin Kretschmar
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs