CommitTicketUpdate does not seem to be checking permission (Git)

57 views
Skip to first unread message

Sylvain Raybaud

unread,
Jul 18, 2014, 11:13:52 AM7/18/14
to trac-...@googlegroups.com
Dear Trac users community,

I'm facing a problem with my company trac installation. I've got a trac installation with a bunch of registered users (usernames and passwords in /var/trac/main/digest). But whoever the author of a changeset is he is able to close a ticket by including the appropriate command in the commit message. Here are the steps to reproduce:

1) Correctly (I think) set permission checking in trac.ini:

root@dev:~# grep commit_ticket_update_check_perms /var/trac/main/conf/trac.ini
commit_ticket_update_check_perms = true

2) Clone a test repository and commit and push changes as a user who does not appear anywhere in trac configuration (neither does the email address):

toto@sylvain-GC:~/boost-cgi$ git clone ssh://git/boost-cgi
toto@sylvain-GC:~/boost-cgi$ git config --global user.name "Toto"
toto@sylvain-GC:~/boost-cgi$ git config --global user.email "x@y.z"
toto@sylvain-GC:~/boost-cgi$ echo "PLOUF" >> hello && git commit -a -m "close #67" && git push
toto@sylvain-GC:~/boost-cgi$ git log -1
commit 37bc8cda563c147ad5d3dec3b032a99d90e74566
Author: Toto <x@y.z>
Date:   Fri Jul 18 14:22:10 2014 +0200

    close #67

3) Watch #67 being closed (mail sent by Trac):

#67: test
-----------------------+----------------------
 Reporter:  sylvain    |       Owner:  sylvain
     Type:  defect     |      Status:  closed
 Priority:  major      |   Milestone:
Component:  boost-cgi  |  Resolution:  fixed
 Keywords:             |
-----------------------+----------------------
Changes (by Toto <x@y.z>):

 * status:  reopened => closed
 * resolution:   => fixed


A peek in source code showed me that Trac checks if the author of the changeset ("Toto", I guess. Or maybe x@y.z? Anyway none has any permission) has permission TICKET_MODIFY. In our installation only "authenticated" users have TICKET_MODIFY permissions.


As I could not find this "bug" documented anywhere I'm very much willing to admit I'm doing something wrong... but I'm really clueless. Any guidance would be appreciated.

Best regards,

Sylvain Raybaud

Ryan Ollos

unread,
Jul 29, 2014, 12:59:28 AM7/29/14
to trac-...@googlegroups.com
You could set log level to DEBUG and post the output that you see when pushing the changeset and closing the ticket.
http://trac.edgewall.org/wiki/TracLogging

Which version of Trac are you running?

Sylvain Raybaud

unread,
Aug 1, 2014, 7:54:18 AM8/1/14
to trac-...@googlegroups.com
On 29/07/2014 06:59, Ryan Ollos wrote:
> <sylvain...@gmail.com <mailto:sylvain...@gmail.com>> wrote:
>
> Dear Trac users community,
>
> I'm facing a problem with my company trac installation. I've got a
> trac installation with a bunch of registered users (usernames and
> passwords in /var/trac/main/digest). But whoever the author of a
> changeset is he is able to close a ticket by including the
> appropriate command in the commit message. Here are the steps to
> reproduce:
>
> [...]
>
>
> You could set log level to DEBUG and post the output that you see when
> pushing the changeset and closing the ticket.
> http://trac.edgewall.org/wiki/TracLogging
>
> Which version of Trac are you running?


Hello

Thanks for your reply. I'm running Trac version 1.1.2dev-r12865.

I did set the loglevel to DEBUG and here is what shows up. I'll skip the
numerous "Trac[loader] DEBUG: Loading ..." to go directly to what seems
relevant:

2014-07-21 13:52:33,862 Trac[loader] DEBUG: Loading
tracopt.versioncontrol.svn.svn_prop from
/usr/local/lib/python2.7/dist-packages/Trac-1.1.2dev_r12865-py2.7.egg

[... and more similar entries before ...]

2014-07-21 13:52:33,863 Trac[default_workflow] DEBUG: Workflow actions
at initialization: {u'resolve': {u'operations': [u'set_resolution'],
'name': u'resolve', 'default': 0, 'newstate': u'clos
ed', 'oldstates': [u'new', u'assigned', u'accepted', u'reopened'],
u'permissions': [u'TICKET_MODIFY']}, u'accept': {u'operations':
[u'set_owner_to_self'], 'name': u'accept', 'default': 0, 'new
state': u'accepted', 'oldstates': [u'new', u'assigned', u'accepted',
u'reopened'], u'permissions': [u'TICKET_MODIFY']}, u'leave':
{u'operations': [u'leave_status'], 'name': u'leave', u'default
': 1, 'newstate': u'*', 'oldstates': [u'*'], 'permissions': []},
u'reopen': {u'operations': [u'del_resolution'], 'name': u'reopen',
'default': 0, 'newstate': u'reopened', 'oldstates': [u'close
d'], u'permissions': [u'TICKET_CREATE']}, u'reassign': {u'operations':
[u'set_owner'], 'name': u'reassign', 'default': 0, 'newstate':
u'assigned', 'oldstates': [u'new', u'assigned', u'accepted
', u'reopened'], u'permissions': [u'TICKET_MODIFY']}, '_reset':
{'operations': ['reset_workflow'], 'name': 'reset', 'default': 0,
'newstate': 'new', 'oldstates': [], 'permissions': []}}

2014-07-21 13:52:33,867 Trac[api] DEBUG: Event changeset_added on
repository 'boost-cgi' for changesets
(u'86034d863b512607f374a0ebfd28f28f4f969662',)
2014-07-21 13:52:33,881 Trac[git_fs] INFO: detected GIT version 1.7.10.4
2014-07-21 13:52:33,882 Trac[PyGIT] DEBUG: PyGIT.Storage instance
58229328 constructed
2014-07-21 13:52:33,882 Trac[PyGIT] DEBUG: requested weak PyGIT.Storage
instance 58229328 for '/home/git/repositories/boost-cgi.git'
2014-07-21 13:52:33,883 Trac[git_fs] DEBUG: disabled CachedRepository
for '/home/git/repositories/boost-cgi.git'

[... many similar lines follow which are not related to this repository ...]

2014-07-21 13:52:33,932 Trac[PyGIT] DEBUG: rebuilt commit tree db for
58229328 with 227 entries (took 31.8 ms)
2014-07-21 13:52:33,950 Trac[PyGIT] DEBUG: git exits with 1, dir:
u'/home/git/repositories/boost-cgi.git', args: config ('--get',
'i18n.commitEncoding'), stderr: ''
2014-07-21 13:52:33,951 Trac[api] DEBUG: Event changeset_added on
repository 'boost-cgi' for revision
'86034d863b512607f374a0ebfd28f28f4f969662'
2014-07-21 13:52:33,953 Trac[commit_updater] DEBUG: Updating ticket #67
2014-07-21 13:52:33,953 Trac[api] DEBUG: action controllers for ticket
workflow: ['ConfigurableTicketWorkflow']
2014-07-21 13:52:33,988 Trac[notification] INFO: Sending notification
through sendmail at /usr/sbin/sendmail to
[u'sylvain...@green-communications.fr',
u'qoly...@green-communications.fr']
2014-07-21 13:52:33,988 Trac[notification] DEBUG: Sendmail command line:
[u'/usr/sbin/sendmail', '-i', '-f', u'ray...@crans.org',
u'sylvain...@green-communications.fr',
u'qoly...@green-communications.fr']


ray...@crans.org is the commiter (not registered anywhere in Trac) and
sylvain...@green-communications.fr is owner of ticket #67

Regards,

Sylvain Raybaud

RjOllos

unread,
Aug 8, 2014, 2:06:45 PM8/8/14
to trac-...@googlegroups.com
2014-07-21 13:52:33,988 Trac[notification] DEBUG: Sendmail command line:


ray...@crans.org is the commiter (not registered anywhere in Trac) and
sylvain...@green-communications.fr is owner of ticket #67

Regards,

Sylvain Raybaud



 - Confirm that commit_ticket_update_check_perms is in the [ticket] section. The value defaults to true anyway, so it seems unlikely this is the issue.
 - Do you have any special permission policies?

You could try adding some logging to line 270:
self.log.info("check_perms = %s, checking TICKET_MODIFY user %s: %s", self.check_perms, authname, 'TICKET_MODIFY' in perm) 
Reply all
Reply to author
Forward
0 new messages