On 21.09.2016 09:06, Florian Schricker wrote:
Unfortunately it still fails.

This time I am attaching a more or less complete log from tracd-start until "recursion error" and the source file of the plugin I am using.

I hope that helps - I am more than willing in testing anything while providing any information I can collect. Any config files or other files of interest? Just let me know.

regards,
Florian

Am Freitag, 16. September 2016 03:16:17 UTC+2 schrieb RjOllos:

    On Tuesday, August 30, 2016 at 12:25:26 AM UTC-7, Florian
    Schricker wrote:

        While this now fixes the Timeline function, modifying tickets
        now fails with the same recursion error. I have not yet
        checked the logs.

        For a better understanding let me ask the following question:

        From my research I was not expecting the policies to
        "interact" with each other recursively at all. I was thinking
        that all configured policies are asked in sequence until some
        policy returns True or False, with returning None just meaning
        "ask the next policy". Where is the recursion? Is it a bug
        in TracPrivateTickets?


It's "mutual recursion". Unfortunately that means it's not a simple bug you can necessarily fix in one plugin alone. It's an unfortunate interaction between the two plugins. The idea was, exactly as you say, to ask each policy in turn. But each plugin basically says: "Hang on, before I answer, let me ask you this first: Is this other thing allowed?" And again each policy is asked in turn about this new question, and so on forever...

Each policy is protected against its own such recursive questions:

Am Freitag, 16. September 2016 03:16:17 UTC+2 schrieb RjOllos:

    There shouldn't be recursion in ReadonlySignedTickets because of
    the check "action == 'TICKET_ADMIN' or 'TICKET_ADMIN' in perm".
    "'TICKET_ADMIN' in perm" will cause a recursive permission check
    for the action TICKET_ADMIN, but when ReadonlySignedTickets is
    called again it will return None due to the "action ==
    'TICKET_ADMIN'" conditional.

But neither policy can detect re-entrancy in general. It only shortcuts its own kind of followup question. Since the other policy asks about a different kind of permission, this is not detected.

It's basically again the same problem as before.

Detailed step-by-step description of events:
1. The initial question is from web_ui.py about TICKET_VIEW.
2. The Permission System asks each policy about this in turn.
3. First it asks the privatetickets policy, which interjects (recursively calls): "To answer that, I first need to know if TICKET_VIEW_REPORTER is available." 4. The Permission System again poses this new question to each policy in turn. 5. First it asks the privatetickets policy, which expected this and replies "None".
    (This is not visible in the stack trace.)
6. Then it asks ReadonlyTicketsPlugin, which interjects:
   "To answer that, I first need to know if TICKET_ADMIN is available."
7. The Permission System again poses this new question to each policy in turn. 8. First it asks the privatetickets policy, which interjects (recursively calls): "To answer that I first need to know if TICKET_VIEW_REPORTER is available".

And since 8. is exactly the same situation as 3. it continues in the same way forever.



The dangerous thing is calling perm.has_permission(action2) inside check_permission(...action1...). But it's only a problem if a second policy calls perm.has_permission(action1) inside check_permission(...action2...).
(Or some similar more complex variations.)

How can this be avoided?
One way is that by convention all policies must make sure not to "go back to an earlier question". For example if all permission actions are ordered somehow (for example TRAC_ADMIN>TICKET_ADMIN>TICKET_VIEW>...) , then inside check_permission(...action1...) only use perm.has_permission(action2) if action2>action1.
But the PrivateTickets policy does not follow such a convention.

I think it's an inherent problem with the design that was not foreseen.
You can sometimes add workarounds for specific situations, as in the first case. In this case it might be easier to add the workaround to the PrivateTickets policy.


Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Reply via email to