TRAC_ADMIN and "You don't have the required permissions."

[risanecek@…]

after a trac upgrade I'm in the usual week-long (hint hint) post-fixing-the-mess (hint hint) process.

Trying to look at a repository I now get

CHANGESET_VIEW privileges are required to perform this operation. You don't have the required permissions.

And that's although I am admin and have TRAC_ADMIN privileges. So at least the statement at https://trac.edgewall.org/wiki/TracPermissions

"To enable all privileges for a user, use the TRAC_ADMIN permission. Having TRAC_ADMIN is like being root on a *NIX system: it will allow you to perform any operation."

is not entirely true here. I also tried trac-admin:

# trac-admin /data/trac/proj/ permission add admin TRAC_ADMIN
The user admin already has permission TRAC_ADMIN.

Trying to add admin to a group that has CHANGESET_VIEW explicitely yields:

"The subject admin was not added to the group G_viewer because the group has BROWSER_VIEW permission and users cannot grant permissions they don't possess."

Oh come on! I am TRAC_ADMIN I am supposed to be allowed to do that.

What does work, is to use trac-admin with this explicit permission:

# trac-admin /data/trac/proj/ permission add admin CHANGESET_VIEW

However, this seems to have no effect on the GUI

Error: Forbidden

CHANGESET_VIEW privileges are required to perform this operation. You don't have the required permissions.

so I'm stuck here for the moment.

[risanecek@…]

Fixed. Log said:

2016-12-08 11:27:44,385 Trac[svn_authz] ERROR: Error accessing authz file: OSError: [Errno 2] No such file or directory: ''

So I added - again -

[svn]
authz_file = /data/trac/proj/conf/svnauthz

to the svn section of trac.ini.

HOWEVER,

The same needs to be in the trac section also now:

[trac]
authz_file = /data/trac/proj/conf/svnauthz

else the svnauthz plugin will not find it. Jeez data deduplication FTW!

[Jun Omae]

InstallationIssue.

[Ryan J Ollos]

Replying to risanecek@…:

Fixed. Log said:

2016-12-08 11:27:44,385 Trac[svn_authz] ERROR: Error accessing authz file: OSError: [Errno 2] No such file or directory: ''

So I added - again -

[svn]
authz_file = /data/trac/proj/conf/svnauthz

Please explain what you mean by "again". On upgrade Trac will move the option authz_file from the [trac] section to the [svn] section in upgrade step 39​. Prior to the upgrade the authz_file option will be in the [trac] section, after the upgrade it will be in the [svn] section. You shouldn't need to do any manually editing of trac.ini. If you edited trac.ini to move the auth_file option from [trac] to [svn] before running the upgrade, that would cause problems.

If you wish to help and improve the Trac upgrade experience (hint), or at the very least help us explain what you might have done wrong, please provide trac.ini and trac.ini.db39.bak from $env/conf, and let us know which Trac version you were upgrading from. Sadly, most people are just concerned with fixing whatever problems they encounter, be that a correct fix or not, and don't provide us the information to determine if there is a problem with Trac.

It sounds like the problems you experienced in comment:description were due to AuthzSourcePolicy not finding authz_file and you came to a number of incorrect conclusions based on the behavior you saw. I could explore whether we could improve the experience with better error messages if you provided the information about your configuration. Open source software can only improve with help from users like yourself (hint).

to the svn section of trac.ini.

HOWEVER,

The same needs to be in the trac section also now:

[trac]
authz_file = /data/trac/proj/conf/svnauthz

else the svnauthz plugin will not find it. Jeez data deduplication FTW!

That looks like an issue with ​th:TracSvnAuthzPlugin. Are you using that plugin? If you wish to help you could report the issue to that plugin maintainer, however it seems the site where the plugin is hosted is unreachable.

We put a lot of effort into trying to make the upgrade experience go smoothly, but can't be responsible for plugins.

[Jun Omae]

AuthzPolicy (tracopt.perm.authz_policy) raises ConfigurationError when the given file in [authz_policy] authz_file option is missing. However, AuthzSourcePolicy doesn't raise any exceptions if the given file in [trac] authz_file option is missing.

I consider we should raise a ConfigurationError if [trac] authz_file is unavailable.

trac/versioncontrol/svn_authz.py

@@ -206 +207 @@
                     return True
 
     def _get_authz_info(self):
+        if not self.authz_file:
+            self.log.error('The `[trac] authz_file` configuration option in '
+                           'trac.ini is empty or not defined.')
+            raise ConfigurationError()
         try:
             mtime = os.path.getmtime(self.authz_file)
         except OSError, e:
             if self._authz is not None:
                 self.log.error('Error accessing authz file: %s',
                                exception_to_unicode(e))
+                raise ConfigurationError()
             self._mtime = mtime = 0
             self._authz = None
             self._users = set()

[Ryan J Ollos]

That looks good, to be consistent with changes in #11272.

[risanecek@…]

@Ryan

"If you wish to help and improve the Trac upgrade experience (hint), or at the very least help us explain what you might have done wrong,[…] Sadly, most people are just concerned with fixing whatever problems they encounter, be that a correct fix or not, and don't provide us the information to determine if there is a problem with Trac."

You may want to re-read that text of yours, then re-read the whole ticket thread, then re-think about the situation as whole and THEN maybe have a chance to draw the right conclusions. "People" will fix the issues they have so "it just somehow works again".

Writing a ticket here happens - at least in my case - only if I am really full of energy and optimism. Most of the time, it's not worth the effort and quite frankly more of a frustrating experience. First off, you should immediately discard ticket states like "Cantfix", "Wontfix", "Invalid" because these are only quasi-polite aliases for "F* you".

Second, "what I may have done wrong" is very easy to explain - I did update the installation on the Gentoo VM that is running the Trac/SVN services. As I know this is ALWAYS coming at a price, I'm postponing it for as long as possible and if security does not allow otherwise, I have to jump into the cold water that is trac update.

Your mind set of a priori thinking "what the user may have done wrong" is the problem here. I did nothing wrong, except upgrading a kludgy system full of badly maintained kludgy plugins.

"If you edited trac.ini to move the auth_file option from [trac] to [svn] before running the upgrade, that would cause problems."

Sure. WHY on earth would I have edited trac.ini BEFORE the upgrade? So no - I didn't. I edited it afterwards, because AS I WROTE svnauthz plugin will not work if authz_file is moved from [trac] to [svn].

The whole "we can't be responsible for plugins" is total rubbish and a cheap excuse. If you really believe that (which I am afraid you do), then you have to re-think SERIOUSLY your plugin politics. Please try to think about the situation "people" using trac are in: They have a running system, more or less kludgy customized for their needs. Every update means hassle - plugins stop working.

For me as a user, there is no difference between a "core" trac and the plugins. For me it's a whole. Ideally, when I would like to update, trac would WARN me, "Plugin XYZ may stop working" so I could investigate that before ending up with a non-working system. Even more ideally, it would sort these things out.

As I was even more full of energy and optimism, I fixed the TracStats plugin and made a pull request, but for the rest of the necessary fixes, I went exactly the way you described above: "Did some kludgy fix so it works." and didn't bother to mention. Why should I? Doesn't look like you care much about software quality in the 1st place.

Hey! It's not a rant. It's feedback with good intentions. You may or may not consider it for some future development, because as is, I'm not sure I'd stick with such a technical-debt-ridden system like trac if some better replacement came along.

[risanecek@…]

Please explain what you mean by "again". On upgrade Trac will move the option authz_file from the [trac] section to the [svn] section in upgrade step 39​.

Exactly. And by doing so, it will break the TracSvnAuthzPlugin, which we are using. So AFTER the update, when that plugin stopped working, I moved that parameter from svn to trac, only to find that the plugin started working, but the source browser stopped working.

⇒ So now I have a copy in trac and svn sections.

From my point of view, the excuse "we can't be responsible for plugins" is even worse in this case. "YOU" did break the plugin with "your" upgrade step 39. If you see the responsibility for that problem at the plugins side, you really have a major issue in the design of the trac update process.

[Ryan J Ollos]

For anyone that encounters this problem, there's a new version of ​TracSvnAuthzPlugin that works with Trac 1.2: ​browser:tracsvnauthzplugin/1.2.