Apache OpenOffice (AOO) Bugzilla – Issue 1515
no tag permission for user rt in dba project
Last modified: 2013-08-07 15:24:38 UTC
the cvs server tells user rt that he has no permission to tag the CVSROOT when he tries to tag the dba project. the detailed user permissions show that he should have the permission to tag. It absolute critical issues that our release engineers have the ability to tag every public CVS module on openoffice.org !
Created attachment 460 [details] Output of "cvs tag -F SRC638" in module connectivity.
There seems to be the same problem for users kz, obo, and hjs.
Hi, We are ivestigating this issue and will keep you updated. If there is any additional information you can provide or users experiencing this problem, please let us know. Thank you Kat
Ruediger - My apologies that we haven't jumped on this yet. I have some requests to help us nail this down. 1. Please include a complete transcript, including your login and checkout and commit commands. 2. You do appear to have the permission to tag the dba module. CVSROOT is a private module; whatever you are attempting, CVS believes you are also attempting to tag the CVSROOT module. Despite this error message, were you in fact able to tag the dba module? 3. Errors follow the attempt to tag files in the dba/workben directory. Are there corrupt files in there? 4. Is this error replicable when you attempt to tag in other modules? 5. If necessary, may we log in as you, reset your password, and attempt to replicate? (We will need a complete trascript of your attempt to do this). 6. Stefan - you understand the modules file. If the attempt to CVS TAG hit a corrupt or unindexed file, would CVS return to the modules file in an attempt to locate it? Would it try something weird like tagging that file? 7. Has anyone outside the releng group encountered this behavior as far as you know? Stefan, can you replicate this?
ad 6. My understanding is that will not do anything weird but output something like ? file as you can see from the attached output.
We have been unable to replicate this problem in the dba module or elsewhere - we were successful in attempting to tag a file within dba using a release engineer user id. There is no functional problem with CVS TAG. Your permissions are set correctly (you do have TAG permission on dba; you do not have TAG permission on CVSROOT). Please make sure that all the files you are trying to tag have been added and committed properly. I suspect this is the cause of the problem. On Tuesday I will mark this issue RESOLVED WORKSFORME.
Cannot replicate; permissions for users are set correctly. Marking RESOLVED WORKSFORME. If this issue gets reopened, please do not prioritize it as a P1.
Meanwhile I found out the circumstances under which I get the error. It depends on the ownership given in the CVS/Root files. If _every_ CVS/Root file in a module points to myself, i.e. it reads :pserver:rt@so-cvs-tunnel:/cvs , I can tag the entire module. I _no_ CVS/Root points at me, I can tag, too. Problems arise in case of mixed ownerships, for example if dbaccess/source/CVS/Root points at user kz, dbaccess/source/ui/CVS/Root points at me, and dbaccess/source/ui/control/CVS/Root at kz again. Than cvs states that user rt doesn't have <Tag> access to project CVSROOT, and nothing in dbaccess/source/ui/ gets tagged. It may sound strange to you to have such mixed user entries in CVS/Root, but that's not uncommon in our environment where several release engineers are working on the same workspace. Knowing about this problem I now patch all CVS/Root files to point at the same user id. Rüdiger
It's good to know the root cause and have a workaround. To avoid misunderstandings I would like to say, that Ruediger mentions a workaround in the last paragraph, but we are still in the need for a fix.
Hi, I will add this information to the internal issue pcn6321 to work toward a solution. Thank you Kat
Hi, Do all users checking out directories into the workspace have permission to tag? If the working copy has different identities recorded in various CVS/Root files, and some of those users don't have Tag permission, then the tag operation will be expected fail for those subdirectories. Thank you Kat
Yes, all of them (hjs, hr, mh, obo, rt, kz, and vg) have tag permission.
This may be related to the behavior documented in issue 1686, which should be addressed by the upgrade, but we are also looking into other causes and solutions. Thank you Kat
the error message is now more precise: cvs tag: cannot find password; use cvs log in first
For me it still looks the same. I checked out module dbaccess cvs co -d:pserver:rt@so-jumbo:/cvs dbaccess changed dbaccess/source/ui/CVS/Root from :pserver:rt@so-jumbo:/cvs into :pserver:kz@so-jumbo:/cvs cd'd to the root directory of module dbaccess and did cvs tag -F tagtest I got the following ~/dbaccess> cvs tag -F tagtest User rt doesnt have <Tag> access to project CVSROOT cvs server: Tagging . cvs server: Tagging inc cvs server: Tagging prj cvs server: Tagging res cvs server: Tagging source cvs server: Tagging source/core cvs server: Tagging source/core/api cvs server: Tagging source/core/dataaccess cvs server: Tagging source/core/inc cvs server: Tagging source/core/misc cvs server: Tagging source/core/resource cvs server: Tagging source/inc cvs server: Tagging source/shared cvs server: Tagging source/ui User rt doesnt have <Tag> access to project CVSROOT cvs server: Tagging util User rt doesnt have <Tag> access to project CVSROOT cvs server: Tagging . cvs server: Tagging source User rt doesnt have <Tag> access to project CVSROOT T makefile.rc Everything beneth dbaccess/source/ui wasn't tagged. Why does it say "User rt doesnt have >Tag> access to project CVSROOT"? I didn't try to do anything with cvsroot. The same is true for user kz. For user mh with some additional privileges everything seems to work as expected.
for user rt there is the same behaviuor with cvs client 1.11 (no access to CVSROOT: T source/shared/stringconstants.cxx T source/shared/stubs.cxx cvs server: Tagging source/ui User rt doesnt have <Tag> access to project CVSROOT cvs server: Tagging util T util/dba.dxp T util/dba.map T util/dbu.dxp T util/dbu.map T util/exports.dxp T util/hidother.src T util/makefile.mk User kz doesnt have <Tag> access to project CVSROOT cvs server: Tagging source User kz doesnt have <Tag> access to project CVS
We are having problems reproducing you exact errors here so our cvs developer would like to do a trace using the pcheck.pl script on the server while you perform this operation. This has now been enabled on the test server now and will be commented out again on Sunday afternoon (PDT) to prevent excessive messages in the debug log. Thank you Kat
Hi, I did the action some minutes ago again, so that the protocol is available for you.
won't be resolved before the upgrade to 1.1 removing dependency
Created attachment 714 [details] Shell script to reproduce described error.
Hi, We were unable to reproduce this error before because out of habit (from working in many repositories) we all specify CVSROOT when performing cvs operations. When the tag is initiated with cvs -d :pserver:releng1@localhost:/cvs tag -F tagtest rather than cvs tag -F tagtest the conflict of the different roots is avoided and the entire project can be tagged. Kat
Our understanding is that both methods are valid and should lead to the same results. Right now I can't oversee if we are able to drop the documented way. Do you think that there is a fix possible in the next time ?
I am asking about the possibilities on the internal issue.
This is still being looked into internally.
Any news?
Curently being investgated. The difference in behavior noted when cvsroot is specified with either the -d option or by setting the environment variable before attempting the tage of the repository is related to this overriding CVS's normal behavior when encountering mixed-user working copies. There is a problem occuring when attempting to employ switching the internal idea of cvsroot according to each cvs/Root file encountered. The basis for this is being investigated.
Some attention has been taken away from this issue to address 2335. Now that the patch has been committed for that issue more effort may be concentrated on this issue. Kat
The developers are concentrating on this issue now and actively tracing down the cause on the staging server. As soon as I am able to provide a time frame for resolution I will make it available here, as well as keep you updated on progress. Thank you Kat
A patch to address this issue has been proposed and is currently in the approval process internally. After this stage passes it will move on to relese engineering and staging. Kat
There is a fix in place on the staging server now to address this issue. After testing and verifiaction are complete we can promote this to the production site. Thank you Kat
Hi, This rpm is now present on the production server. Please notify us if there are any problems. Thank you Kat
I just tested it the same way as I did it before: checked out module dbaccess cvs co -d:pserver:rt@so-jumbo:/cvs dbaccess changed dbaccess/source/ui/CVS/Root from :pserver:rt@so-jumbo:/cvs into :pserver:kz@so-jumbo:/cvs cd'd to the root directory of module dbaccess and did cvs tag -F tagtest Good news: no error messages any more. Bad news: it still doesn't work. Nothing beneath dbaccess/source/ui get's tagged.
Reassigning all of kat's open issues to support so that I can go through them.
I'll take a look at this.
I've reopened the internal issue (PCN6321).
We created a new iternal issue (PCN7721) to continue the work from the previous issue. I'm working with the engineer to replicate the most recent symptoms and find a fix.
Ruediger: I took a look at your dbaccess tags, and I'm confused. I don't see the tagtest even on files which are in /dbaccess/ but not in /dbaccess/source/. Here's the test that I did: In the collabnet directory, I created a few testfiles at the root and a few in the testingdir/ directory. I logged in as taska and checked out collabnet. I deleted collabnet/testingdir/. I logged out as taska. I logged in as taskatest and checked out collabnet/testingdir/. I logged in as taska. (Now I was logged in as both taska and taskatest.) I tagged: [taska@localhost openofficetest]$ cvs -d :pserver:taska@cvs.openoffice.org:/cvs tag taskatesttag3 cvs server: Tagging collabnet T collabnet/testing1.txt T collabnet/testing2.txt cvs server: Tagging collabnet/testingdir T collabnet/testingdir/testing3.txt T collabnet/testingdir/testing4.txt cvs server: Tagging collabnet/www T collabnet/www/index.html I checked testing1.txt and testing3.txt with cvs log and they both show the tag. A few questions: - were you logged in as both users? - could you paste the entire response to cvs tag in here? - could you tell me the name of a file where the tag did "stick"? Thanks.
Hi Taska, Yes, doing it this way is fine. But please look at the comments by Kathy Gavin (2001-11-20 17:10 PST) and Martin Hollmichel (2001-11-21 09:41 PST). Does the tagging work for you without specifying CVSROOT explicitly? Rüdiger
Ruediger, okay, here is the log of my new test. Could you tell me how what I am doing is differing from what you are doing? ----- [taska@localhost openofficetest]$ cvs -d :pserver:taska@cvs.openoffice.org:/cvs login (Logging in to taska@cvs.openoffice.org) CVS password: [taska@localhost openofficetest]$ cvs -d :pserver:taska@cvs.openoffice.org:/cvs co collabnet cvs server: Updating collabnet U collabnet/testing1.txt U collabnet/testing2.txt cvs server: Updating collabnet/testingdir U collabnet/testingdir/testing3.txt U collabnet/testingdir/testing4.txt cvs server: Updating collabnet/www U collabnet/www/index.html [taska@localhost openofficetest]$ cvs -d :pserver:taska@cvs.openoffice.org:/cvs logout (Logging out of taska@cvs.openoffice.org) [taska@localhost openofficetest]$ rm -rf collabnet/testingdir/ [taska@localhost openofficetest]$ cvs -d :pserver:taskatest@cvs.openoffice.org:/ cvs login (Logging in to taskatest@cvs.openoffice.org) CVS password: [taska@localhost openofficetest]$ cvs -d :pserver:taskatest@cvs.openoffice.org:/ cvs co collabnet/testingdir cvs server: Updating collabnet/testingdir U collabnet/testingdir/testing3.txt U collabnet/testingdir/testing4.txt [taska@localhost openofficetest]$ cvs -d :pserver:taska@cvs.openoffice.org:/cvs login (Logging in to taska@cvs.openoffice.org) CVS password: [taska@localhost openofficetest]$ cd collabnet/ [taska@localhost collabnet]$ cvs tag taskanewtesttag1 cvs server: Tagging . T testing1.txt T testing2.txt cvs server: Tagging www T www/index.html cvs server: Tagging testingdir T testingdir/testing3.txt T testingdir/testing4.txt [taska@localhost collabnet]$ ---- CVS log for testing1.txt: RCS file: /cvs/collabnet/testing1.txt,v Working file: testing1.txt head: 1.1 branch: locks: strict access list: symbolic names: taskanewtesttag1: 1.1 taskatesttag3: 1.1 taskatesttag2: 1.1 taskatesttag1: 1.1 keyword substitution: kv total revisions: 1; selected revisions: 1 description: ---------------------------- revision 1.1 date: 2002/01/24 21:52:59; author: taska; state: Exp; testing ============================================================================= --- CVS log for testing3.txt: RCS file: /cvs/collabnet/testingdir/testing3.txt,v Working file: testingdir/testing3.txt head: 1.1 branch: locks: strict access list: symbolic names: taskanewtesttag1: 1.1 taskatesttag3: 1.1 keyword substitution: kv total revisions: 1; selected revisions: 1 description: ---------------------------- revision 1.1 date: 2002/01/24 21:53:41; author: taska; state: Exp; testing =============================================================================
Ruediger: so, in summary, the answer to your above question (Does tagging work for me without specifying CVSROOT explicitly) is yes. If you could attach a transcript and a few cvs log outputs to this issue, and reassign to me, I will look at them and figure out what we are doing differently. Thanks!
Hi Taska, Thanks for trying it without specifying CVSROOT explicitly. To answer your question what is different between your and my test scenario: you have just one level of subdirectories, I used several. I just tried what you did in module offmgr with some subdirectores more handy (i.e. with less content) than those in dbaccess where I found it originally: - checked out offmgr/prj (no further subdirectories) as releng1 - removed subdirectory prj - checked it out again as user releng2 Now offmgr/CVS/Root was :pserver:releng1@so-cvs-tunnel:/cvs and offmgr/prj/CVS/Root :pserver:releng2@so-cvs-tunnel:/cvs - cd offmgr; cvs tag -F TAGTEST => OK, as in your test. Than I did - check out offmgr/util/defs as releng1 - remove offmgr/util/defs - check it out again as releng2 Now we have offmgr/CVS/Root :pserver:releng1@so-cvs-tunnel:/cvs offmgr/util/CVS/Root :pserver:releng1@so-cvs-tunnel:/cvs offmgr/util/defs/CVS/Root :pserver:releng2@so-cvs-tunnel:/cvs - cd offmgr; (that means changing CVS/Root entries beneath where I am.) cvs tag -F TAGTEST results in cvs server: Tagging . cvs server: Tagging util cvs server: Tagging . cvs server: Tagging util Nothing inside util/defs get's tagged. So perhaps you could mkdir collabnet/testingdir/testsubdir any try tagging when testingdir and testsubdir have different CVS/Root entries? Rüdiger
Dear Ruediger, hmm, that is very interesting. It would be *VERY* helpful if you could include a full transcript including the commands you ran and all of the results. That would be better than paraphrasing the differences. Also, please reassign back to support@openoffice.org or the issue may "fall through the cracks" and get lost. Thanks!
Created attachment 1003 [details] transcript including subdirs
Dear Ruediger- I've added an attachment showing that the subdirectories cause no problems in the collabnet project. In order to troubleshoot this further I need a full, line-by-line transcript of what you are doing which is resulting in this error. Thanks.
Created attachment 1005 [details] Test script (shell script) to reproduce the error.
Created attachment 1006 [details] Transcript of shell script iz1515.co.
Taska, I attached a schell script to reproduce what I did (iz1515.co). Before running this script you have to login as users releng1 and releng2. I also attached the output I got from this script. Hope this helps. Rüdiger
Created attachment 1007 [details] Variant if iz1515.co using rm and re-checkout.
I looked at your script and ran something similar (without going through the tunnel) both using taska/taskatest, and releng1/releng2. Ta-da! The problem occurs when using releng1/releng2, but not when using taska/taskatest. I have a number of hypotheses- I will test them one-by-one.
I switched taskatest/taskatest2 from being domain admins to being regular users with membership in the "Release Engineers" user group; and I gave the "Release Engineers" Developer membership in the collabnet project. I was able to replicate the problem there. When I removed the group membership and gave taskatest/taskatest2 domain admin once more, the problem went away. Still researching.
Our CVS developers are going to set up the system for an in-depth test.
Okay, we've created and retrieved the applicable logs from the live server, and our developers are looking at them.
Our developers have been illuminated by the pcheck.log file from the server and will be working on a fix tomorrow.
The developers have completed and tested the fix; we need to roll it up into an rpm and bring it live.
We've brought our fix live, and I've made a successful test on the live box. Please verify.
Great, now it works (see below). Thanks! Rüdiger rt94443@blauwal(10:12):~/test1515> ./iz1515.co cvs server: Updating offmgr/util U offmgr/util/funcord.w16 U offmgr/util/hidother.hrc U offmgr/util/hidother.src U offmgr/util/libofa569li.so.mapfile U offmgr/util/libofa569ss.so.mapfile U offmgr/util/makefile.mk U offmgr/util/makefile.pmk U offmgr/util/ofapch.cxx cvs server: Updating offmgr/util/defs U offmgr/util/defs/wntmsci3 U offmgr/util/defs/wntmsci7 U offmgr/util/defs/wntmsci8 patching offmgr/util/defs/CVS/Root now try to tag: cvs server: Tagging . cvs server: Tagging util T util/funcord.w16 T util/hidother.hrc T util/hidother.src T util/libofa569li.so.mapfile T util/libofa569ss.so.mapfile T util/makefile.mk T util/makefile.pmk T util/ofapch.cxx cvs server: Tagging util cvs server: Tagging util/defs T util/defs/wntmsci3 T util/defs/wntmsci7 T util/defs/wntmsci8 Result in subdirectory util: tagtest: 1.17 Result in subdirectory util/defs: cvs [server aborted]: no such directory `util/defs' tagtest: 1.58 rt94443@blauwal(10:13):~/test1515> cvs tag -d tagtest cvs server: Untagging . cvs server: Untagging util D util/funcord.w16 D util/hidother.hrc D util/hidother.src D util/libofa569li.so.mapfile D util/libofa569ss.so.mapfile D util/makefile.mk D util/makefile.pmk D util/ofapch.cxx cvs server: Untagging util cvs server: Untagging util/defs D util/defs/wntmsci3 D util/defs/wntmsci7 D util/defs/wntmsci8 rt94443@blauwal(10:15):~/test1515/offmgr>
As mentioned on the qa dev list on March 5th I will close all resolved <wontfix/duplicate/worksforme/invalid> issues. Please see this posting for details.