SID-00994: Permissions problem with running MailNotify via cron

Status:	Answered	TWiki version:	4.3.1	Perl version:	5.8.8
Category:	CategoryAccessControl	Server OS:	CentOS 5.5	Last update:	15 years ago

I have debugged my problem to where I know what is happening, but need a solution.

My situation is that I'm running the mailnotify tool via a cron job run as apache. On webs where I have ALLOWWEBVIEW set to something (i.e. non-null), mailnotify properly figures out what the changes are, but fails to send any emails. checkAccessPermission in Access.pm returns 0 (so no mail is sent) because "access not allowed on web" (ie. the user is not in the list of those allowed, but I did add apache as a user to ALLOWWEBVIEW). After dumping what $user is set to (BaseUserMapping_666, which I believe is the default user (because my cron job didn't log in?)), I figure that I need a way to login from my cron job before calling mailnotify.

Anyone have any ideas on how to do that (or have a better way to fix the problem)?

I don't think that it matters, but my authentication is set to: TWiki::LoginManager::TracOnTwikiLogin

-- RayMikkelson - 2010-10-11

Discussion and Answer

How does your crontab entry look like? If you use wget to call the script you get into permission issues. You can call the script as a shell command, which gets around the access control issue. Details in MailerContrib.

-- PeterThoeny - 2010-10-11

The test that fails in Access.pm (checkAccessPermission) is:

unless( $this->{session}->{users}->isInList( $user, $allowText ))

I've dumped both $user and $allowText. They are:

$user = BaseUserMapping_666
$allowText = %MAINWEB%.TWikiAdminGroup, %MAINWEB%.BusinessGroup, Main.WebServer

(Where the login for WebServer is apache.)

I've run this both from cron and from the command line, logged in as apache. My cron entry (the script that is called) looks like:

#!/bin/sh

cd /www/apps/twiki/twiki431/
perl -I /www/apps/twiki/twiki431/bin /www/apps/twiki/twiki431/tools/mailnotify -q

I basically ran the same 2 commands from the shell prompt with the same results.

I took the -q argument off of mailnotify, and can see that the tool finds the changed topics, but when it goes to send the email, checkAccessPermissions fails and nothing is sent.

I've read the MailerContrib page. Nothing there seems to address this problem. Again, this works fine for webs without an ALLOWWEBVIEW parameter being set. BTW, I think that the MailerContrib page should mention that the cron job should be run as apache (and not as root, which is what will happen if you put the file in /etc/cron.daily, if I'm correct about apache being the better login.)

Thanks for any help that you might be able to give...

-- RayMikkelson - 2010-10-11

Hmm, not sure. For testing can you change from Trac auth of TracOnTWikiContrib to TWiki's internal password auth?

-- PeterThoeny - 2010-10-11

I figured it out!!!!

You won't believe what the problem was....

On the Customer/WebNotify page, you must put the entries like so:

   * Main.RayMikkelson
   * Main.User2
   * Main.User3

Putting something like the following doesn't work (even though that's the example that the TWiki itself gives on the WebNotify topic):

   * Main.TWikiGuest - guest@example.com
   * Main.RayMikkelson - Ray.Mikkelson@example.com

It turns out that if you put the 2nd format, the code looks for your email address as a user, and can't find it... (It ignores the Main.User and uses the email instead.)

(Note that the other webs work because they don't need to compare to the ALLOWWEBVIEW parameter, since they're null.)

I found that there's 2 checkAccessPermissions routines... One calls the other, interestingly enough... And, before one calls the other, it changes the username passed in to a cUID (canonical UID)... I can see the code passing in Ray.Mikkelson@uniquesoftPLEASENOSPAM.com, for example, and getting converted to BaseUserMapping_666 before the lower-level checkAccessPermissions gets called.

I think that the WebNotify topic should be updated in the distribution archive. And perhaps the MailNotify topic as well.

-- RayMikkelson - 2010-10-11

I am glad you figured it out!

Hmm, that looks like a bug that needs to be fixed. Could you file one? Specify expected behavior. Also, if you provide a patch there is a good chance that it quickly gets accepted for the next patch release.

-- PeterThoeny - 2010-10-12

To be honest, I don't know whether it's really a bug or not (I tend to think not). I think that the issue is more one of documentation and the WebNotify topic providing a bad example for users to follow. The users here just followed the (incorrect) example given in the topic, which does work if you don't use the ALLOWWEBVIEW parameter for the web. In fact, at the bottom of the WebChangesAlert (not the WebNotify topic) topic, there is a warning message:

Warning: Because an email address is not linked to a user name, there is no way for TWiki to check access controls for subscribers identified by email addresses. A subscriber identified by an email address alone will only be sent change notifications if the topic they are subscribed to is readable by guest users.

So, one can view the problem in one of two ways:

1. There's a bug in the code in that it seems to prefer using the email instead of the 'username' (UserName) when both are specified
2. The documentation is wrong/misleading and should instruct users not to specify email addresses, and if they must (because they don't have a login), they shouldn't expect notifications for restricted webs. Certainly, at a minimum, the given example should definitely be updated.

I'll go ahead and open a ticket, but someone will need to decide which (the code or the documentation) should be fixed.

-- RayMikkelson - 2010-10-12

I opened: TWikibug:Item6595: Notifications fail when ALLOWWEBVIEW is used and users follow the example to subscribe

-- RayMikkelson - 2010-10-12

Thanks Ray.

-- PeterThoeny - 2010-10-12

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.