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