| Title | Users can "fix" issues that they don't have permission to change |
| Status | closed |
| Priority | optional |
| Assigned user | Richard Brooksby |
| Organization | Perforce |
| Description | A user can change the status for a job, and the corresponding defect tracker issue will change in status, even if the user doesn't own or have permission to change it. The user has to sneak in an illegal "p4 fix" after a legitimate user has edited the job and then delete the fix. |
| Analysis | Creating a fix changes the status of a job but does not update the "P4DTI-user" field, so the replicator can't tell who really changed the status. So it updates the DT issue in the name of whoever last changed the job. If that's the replicator (which has permission to change anything) then the issue will get changed. And in any case, the wrong person gets recorded as having made the change. RB 2000-11-28 This has the same underlying cause as job000016, job000042 and job000133. This problem is much reduced in severity when the replicator user in TeamTrack is given only "connect using the API" privilege, as we now recommend in the AG. Then the replicator doesn't have permission to transition issues, so the risk of a user closing an issue they don't have permission to is reduced: they have to sneak in immediately after a user with the right privilege has edited the job. GDR 2000-12-06. But since the replicator can't tell who really changed the job by fixing, we have to assume it was the defect tracking issue's owner (to fix job000133), but this assumption may be false, and introduces the same security hole. RB 2000-12-06 This has similar symptoms to job000137, but a different cause. GDR 2000-12-30 GDR 2001-07-17: This is much ameliorated by the job_modifier() code that fixed job000270. Mostly this will guess the right person and so the right permissions will be applied. However, if someone makes a fix and then deletes the fix within the poll period, the replicator will guess the wrong modifier and apply the wrong permissions. So this is very similar to job000276. |
| How found | inspection |
| Evidence | Originally came up in discussion with NB and GDR on 2000-11-28. |
| Observed in | 0.4.0 |
| Test procedure | <http://www.ravenbrook.com/project/p4dti/master/test/test_p4dti.py>, section 21 |
| Created by | Richard Brooksby |
| Created on | 2000-11-28 16:24:47 |
| Last modified by | Gareth Rees |
| Last modified on | 2002-01-28 18:19:15 |
| History | 2000-11-28 RB Created. 2000-12-06 GDR Added note about reduction in severity and connection to job000042 and job000133. 2000-12-06 RB Added connection to the workaround for job000133 and security implications. 2000-12-30 GDR Noted relation to job000137. 2001-07-17 GDR Downgraded to optional since job_modifier mostly gets it right. Noted relation to job000270, job000276. |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 26176 | closed | 2002-01-28 20:50:48 | Gareth Rees | Don't replicate changes in Perforce that we made in the previous poll. Perforce interface records server changelevel. In Perforce 2002.1, use the P4DTI-user field as an accurate guide as to who last edited the job. |
| 10465 | open | 2001-03-23 08:06:05 | Gareth Rees | New method job_modifier() in replicator.py makes a best guess at who last modified the job, by considering (1) the user who made the most recent fix (if any made since the job was last modified); (2) the user in the P4DTI-user field of the job (if that's not the replicator); (3) the owner of the job. |