Hello,
since CVS doesn't requires the suid bit set, it is a pretty
normal program. Thus the normal file protections for imple-
menting a directory based access control work should be very
easy to implement. For the test setup 'user1' should be able
to read and commit, 'user2' should just be able to read:
For Linux to Linux via remove shell this works like a charm:
cvs -d ":ext:user1@remote:/data/cvshome"
commit -m "" LibSub.htm
user1@remote's password:
Checking in LibSub.htm;
/data/cvshome/GP/LibSub/LibSub.htm,v <-- LibSub.htm
new revision: 1.16; previous revision: 1.15
done
cvs -d ":ext:user2@remote:/data/cvshome"
commit -m "" LibSub.htm
user2@remote's password:
Checking in LibSub.htm;
/data/cvshome/GP/LibSub/LibSub.htm,v <-- LibSub.htm
new revision: 1.17; previous revision: 1.16
cvs [server aborted]: could not open lock file
`/data/cvshome/GP/LibSub/,LibSub.htm,': Permission denied
However with WinCVS and .rhosts identification things
start to look strange. Starting with 'user2' we geht:
cvs commit -m "no message" LibSub.htm (in directory C:\GP\LibSub)
Checking in LibSub.htm;
/data/cvshome/GP/LibSub/LibSub.htm,v <-- LibSub.htm
new revision: 1.17; previous revision: 1.16
cvs [server aborted]: could not open lock file
`/data/cvshome/GP/LibSub/,LibSub.htm,': Permission denied
NEW CVSROOT: user1@remote:/data/cvshome (.rhosts authentication)
cvs commit -m "no message" LibSub.htm (in directory C:\GP\LibSub)
Checking in LibSub.htm;
/data/cvshome/GP/LibSub/LibSub.htm,v <-- LibSub.htm
new revision: 1.17; previous revision: 1.16
cvs [server aborted]: could not open lock file
`/data/cvshome/GP/LibSub/,LibSub.htm,': Permission denied
Restarting WinCVS and and having 'user1' as default gives:
cvs commit -m "no message" LibSub.htm (in directory C:\GP\LibSub)
Checking in LibSub.htm;
/data/cvshome/GP/LibSub/LibSub.htm,v <-- LibSub.htm
new revision: 1.17; previous revision: 1.16
done
NEW CVSROOT: user2@remote:/data/cvshome (.rhosts authentication)
cvs commit -m "no message" LibSub.htm (in directory C:\GP\LibSub)
Checking in LibSub.htm;
/data/cvshome/GP/LibSub/LibSub.htm,v <-- LibSub.htm
new revision: 1.18; previous revision: 1.17
done
Restarting WinCVS again still allows 'user2' to commit:
CVSROOT: user2@remote:/data/cvshome (.rhosts authentication)
TCL is *not* available, shell is disabled
cvs commit -m "no message" LibSub.htm (in directory C:\GP\LibSub)
Checking in LibSub.htm;
/data/cvshome/GP/LibSub/LibSub.htm,v <-- LibSub.htm
new revision: 1.19; previous revision: 1.18
done
So we seems to have a sort of a "memory" effect in the NT to Linux
environment. Has this kind of error been encountered before? Any
ideas and/or suggestions are welcome. With SSH I encountered the
first problems of this kind.
Regards,
Martin Kretschmar
Dipl.-Phys. Dr. Martin Kretschmar
Software Development Corporate Info Center
Infoman AG, Vaihinger Stra�e 169, D-70567 Stuttgart
Tel.: +49 711/67971-682, Fax: +49 711/67971-10
E-Mail: [EMAIL PROTECTED]
Dipl.-Phys. Dr. Martin Kretschmar
Software Development Corporate Info Center
Infoman AG, Vaihinger Stra�e 169, D-70567 Stuttgart
Tel.: +49 711/67971-682, Fax: +49 711/67971-10
E-Mail: [EMAIL PROTECTED]
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
