https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #1 from mjnkml@gmail.com --- Created attachment 57947 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=57947&action=edit Full error as displayed in the email -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #3 from mjnkml@gmail.com --- After separating Failure.pm, the emails are now showing the same problem with Success.pm. After extracting Success.pm in the same way, now it complains about Exceptions.pm : Can't locate Koha/Exceptions/Exception.pm: ./Koha/Exceptions/Exception.pm: Permission denied at /usr/share/perl/5.22/base.pm line 97, <DATA> line 755 Seems like a problem with the build, or (the current version of?) perl not supporting multiple classes within a .pm file? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 mjnkml@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mjnkml@gmail.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #5 from mjnkml@gmail.com --- Separating Exception.pm seemed to have broken other things, so I've backed out of it. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 alfre69 <alfre@ibdinternet.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alfre@ibdinternet.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Liz Rea <liz@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |liz@catalyst.net.nz --- Comment #8 from Liz Rea <liz@catalyst.net.nz> --- On affected servers, changing the /etc/cron.d/koha-common job for process message queue to the following: */15 * * * * root cd /tmp && koha-foreach --enabled --email /usr/share/koha/bin/cronjobs/process_message_queue.pl seems to end run the issue. Thanks to Chris C. for the work around. As Chris says: <rangi> its a permissions issue, something in perl 5.22 has changed <rangi> its not actually a Koha problem, there are a few perl modules that have the same problem -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #10 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- What should we do about this? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Barton Chittenden <barton@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=16138 CC| |barton@bywatersolutions.com --- Comment #12 from Barton Chittenden <barton@bywatersolutions.com> --- Note: this seems to be the same compilation error that was tripping up plack in Bug 16138 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Larry Baerveldt <larry@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |larry@bywatersolutions.com --- Comment #14 from Larry Baerveldt <larry@bywatersolutions.com> --- Just a FYI on this. I found that *not* using koha-foreach, and instead use the actual koha instance user also works. For example, instead of: root koha-foreach --enabled --email /usr/share/koha/bin/cronjobs/process_message_queue.pl if you use: INST-koha /usr/share/koha/bin/cronjobs/process_message_queue.pl it works. So taking a look at how koha-foreach switches to the user might provide some clues. Can confirm this also happens on Debian 8.4. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@bugs.koha-c | |ommunity.org --- Comment #15 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- So, what do we do? Do we release 17.05 as it or we propose a workaround? Is the `cd /tmp` trick added to the cron line acceptable? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #17 from Chris Cormack <chris@bigballofwax.co.nz> --- I am working on replacing this module with one that supports CAS 2.0 and doesnt have this problem. It won't obviously be ready in time though. So I will write a patch to add the cd /tmp && and attach it to here. Should be ready soon -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Mason James <mtj@kohaaloha.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mtj@kohaaloha.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Josef Moravec <josef.moravec@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #63676|0 |1 is obsolete| | --- Comment #20 from Josef Moravec <josef.moravec@gmail.com> --- Created attachment 63677 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=63677&action=edit [SIGNED-OFF] Bug 17717 : Work around for the permissions problem when running process_message_queue To test 1/ Make sure some things are in the message queue 2/ Run the cron jobs, notice nothing is sent 3/ Build and install a new package (or manually update the /etc/cron.d/koha-common file) 4/ Run the jobs again, notice mail is sent Signed-off-by: Josef Moravec <josef.moravec@gmail.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|gmcharlt@gmail.com |chris@bigballofwax.co.nz --- Comment #22 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- (In reply to Julian Maurice from comment #21)

This bug really confuses me.

Same here :) Chris do you have the answers? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #24 from Julian Maurice <julian.maurice@biblibre.com> --- I've made a fresh install on Debian stretch (Perl 5.24) but I can't reproduce the problem. root@koha-stretch:~# sudo -u koha sh -c 'touch test' touch: cannot touch 'test': Permission denied root@koha-stretch:~# sudo -u koha sh -c 'ls' ls: cannot open directory '.': Permission denied As you can see I have no read nor write access to this directory, but when I execute root@koha-stretch:~# sudo -u koha sh -c 'PERL5LIB=/home/koha/koha KOHA_CONF=/home/koha/etc/koha-conf.xml perl /home/koha/koha/misc/cronjobs/process_message_queue.pl' I have no errors and the message queue is processed. Can you tell me what I'm doing wrong ? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #26 from Julian Maurice <julian.maurice@biblibre.com> --- # cat /etc/cron.d/koha * * * * * root sudo -u koha sh -c 'PERL5LIB=/home/koha/koha KOHA_CONF=/home/koha/etc/koha-conf.xml perl /home/koha/koha/misc/cronjobs/process_message_queue.pl > /tmp/koha.log 2>&1' * * * * * root sudo -u koha sh -c 'pwd > /tmp/pwd.log 2>&1' /tmp/pwd.log contains "/root" /tmp/koha.log is empty, and the message queue is processed -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #28 from Julian Maurice <julian.maurice@biblibre.com> --- I've read the history of the bug, many times, and I understand that the problem is with the package install, which I'm trying to mimic to understand what's happening. If my command succeeds, why the one with koha-foreach should fail ? Anyway I'll try with a package install later when I have more time -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 alfre69 <alfre@ibdinternet.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|alfre@ibdinternet.com | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #31 from Julian Maurice <julian.maurice@biblibre.com> --- I let the cron do it, as Chris suggested in comment 25. The only thing I modified in the cron entry is '*/15' to get it launched every minute -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #33 from Julian Maurice <julian.maurice@biblibre.com> --- (In reply to Marcel de Rooy from comment #32)

Is there a difference between the standard koha-foreach with a sudo koha user and the sudo you added in your cron job ? Are the permissions of your koha user identical ? I'm not sure what you are talking about. I used the /etc/cron.d/koha-common shipped with the debian package, and I didn't change the permissions of the 'koha1-koha' user created by koha-create.

I didn't modify the sudoers file either (http://paste.koha-community.org/435) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #35 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- And what about the difference between perl 5.22 and 5.24 ? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #37 from Julian Maurice <julian.maurice@biblibre.com> --- Same with Ubuntu 16.10/Perl 5.22/koha-common 16.11.08 I'm running out of ideas... Does any other QAer want to try ? :) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WORKSFORME Status|Signed Off |RESOLVED --- Comment #39 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Ok, I managed to reproduce the conditions that trigger the bug. GOOD NEWS: It is fixed in master, 16.11 and 16.05 already, as a side effect from bug 16733. The problem was in koha-foreach code, that is not using koha-shell but crafting its own env instead. To reproduce the problem, as a root user run: root$ echo $PERL5LIB <empty> root$ . /usr/share/koha/bin/koha-functions.sh root$ adjust_paths_dev_install kohadev root$ echo $PERL5LIB /home/vagrant/kohaclone So, if adjust_paths_dev_install is not ran, and the command is run by root, PERL5LIB is empty, and perl uses the fallback for include (i.e. '.'). This are the conditions in which cron.d/koha-common runs process_message_queue.pl. This happened in koha-foreach code, before bug 16733. This is the relevant code in debian/scripts/koha-foreach: for name in $(koha-list $listopts) do # Optionally use alternative paths for a dev install adjust_paths_dev_install $name cmd=`echo "$@" | sed -e s/__instancename__/${name}/g` ( exec 3>&1 sudo -u "$name-koha" \ env PERL5LIB=$PERL5LIB \ KOHA_CONF="/etc/koha/sites/$name/koha-conf.xml" \ ${cmd} 2>&1 >&3 | sed -e "s/^/$name: /" >&2 3>&- exec 3>&- ) | sed -e "s/^/$name: /" done So before the 16733 backport, PERL5LIB was incorrectly set. This script should definitely run koha-shell -c "${cmd}" $name instead of crafting all the environment variables. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Marco Moreno <mmoreno@pobox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mmoreno@pobox.com Status|RESOLVED |REOPENED Resolution|WORKSFORME |--- --- Comment #40 from Marco Moreno <mmoreno@pobox.com> --- This issue is NOT fixed in 17.05. I'm seeing this now after having upgraded from 16.11. However, I've discovered some things that might be helpful. As Chris mentioned, this appears to be a bug with base.pm (IMO). Perhaps it's behavior has changed due to this security resolution that forces Perl to die if a required module is cannot be read when traversing @INC: https://rt.perl.org/Public/Bug/Display.html?id=113422 According to this post, base.pm may attempt to require a module that does not exist and traverse the entire @INC array: https://rt.cpan.org/Public/Bug/Display.html?id=106552#txn-1589169 Evidently, it dies as soon as it encounters a directory it cannot read. Avoiding '.' in PERL5LIB doesn't really help since Perl already includes '.' in @INC (also a security concern???). Working around this means either ensuring that '.' points to a directory that can be read (e.g. "cd /tmp") or modifying the @INC array to remove '.' from it. The latter seems better so I modified the BEGIN block in /usr/share/koha/bin/kohalib.pl like this: ------------------------------------- use strict; #use warnings; FIXME - Bug 2505 my $module_dir; BEGIN { $module_dir = '/usr/share/koha/lib'; die if $module_dir =~ /^[_]{2}PERL_MODULE_DIR[_]{2}$/; @INC = grep {$_ ne '.'} @INC; } use lib $module_dir; 1; ------------------------------------- This also allows the change to be in one place and avoid having to insert a 'cd /tmp' for each cron job. I'm running Perl 5.22 - I wonder if it's fixed in 5.24. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #42 from Marco Moreno <mmoreno@pobox.com> --- ubuntu@koha:~$ sudo -i root@koha:~# sudo -u library-koha perl -MAuthen::CAS::Client -e 'print "Ok\n"' Can't locate Authen/CAS/Client/Response/Failure.pm: ./Authen/CAS/Client/Response/Failure.pm: Permission denied at /usr/share/perl/5.22/base.pm line 97. ...propagated at /usr/share/perl/5.22/base.pm line 106. BEGIN failed--compilation aborted at /usr/share/perl5/Authen/CAS/Client/Response.pm line 68. Compilation failed in require at /usr/share/perl5/Authen/CAS/Client.pm line 8. BEGIN failed--compilation aborted at /usr/share/perl5/Authen/CAS/Client.pm line 8. Compilation failed in require. BEGIN failed--compilation aborted. root@koha:~# cd /tmp root@koha:/tmp# sudo -u library-koha perl -MAuthen::CAS::Client -e 'print "Ok\n"' Ok root@koha:~# perl -Mbase -e 'print "$base::VERSION\n"' 2.22 root@koha:~# perl -V Summary of my perl5 (revision 5 version 22 subversion 1) configuration: Platform: osname=linux, osvers=3.16.0, archname=x86_64-linux-gnu-thread-multi uname='linux localhost 3.16.0 #1 smp debian 3.16.0 x86_64 gnulinux ' config_args='-Dusethreads -Duselargefiles -Dcc=x86_64-linux-gnu-gcc -Dcpp=x86_64-linux-gnu-cpp -Dld=x86_64-linux-gnu-gcc -Dccflags=-DDEBIAN -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Dldflags= -Wl,-Bsymbolic-functions -Wl,-z,relro -Dlddlflags=-shared -Wl,-Bsymbolic-functions -Wl,-z,relro -Dcccdlflags=-fPIC -Darchname=x86_64-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.22 -Darchlib=/usr/lib/x86_64-linux-gnu/perl/5.22 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/x86_64-linux-gnu/perl5/5.22 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.22.1 -Dsitearch=/usr/local/lib/x86_64-linux-gnu/perl/5.22.1 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Duse64bitint -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -Ui_libutil -Uversiononly -DDEBUGGING=-g -Doptimize=-O2 -dEs -Duseshrplib -Dlibperl=libperl.so.5.22.1' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='x86_64-linux-gnu-gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2 -g', cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='5.3.1 20160311', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678, doublekind=3 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16, longdblkind=3 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='x86_64-linux-gnu-gcc', ldflags =' -fstack-protector-strong -L/usr/local/lib' libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt perllibs=-ldl -lm -lpthread -lc -lcrypt libc=libc-2.21.so, so=so, useshrplib=true, libperl=libperl.so.5.22 gnulibc_version='2.21' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib -fstack-protector-strong' Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS PERL_DONT_CREATE_GVSV PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP PERL_NEW_COPY_ON_WRITE PERL_PRESERVE_IVUV USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LOCALE_TIME USE_PERLIO USE_PERL_ATOF USE_REENTRANT_API . . . Built under linux Compiled at Mar 13 2016 11:54:18 @INC: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.22.1 /usr/local/share/perl/5.22.1 /usr/lib/x86_64-linux-gnu/perl5/5.22 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.22 /usr/share/perl/5.22 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base . -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Magnus Enger <magnus@libriotech.no> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |magnus@libriotech.no --- Comment #44 from Magnus Enger <magnus@libriotech.no> --- I ran into this problem after upgrading from Koha 3.22, Ubuntu 14.04, Perl ? to Koha 17.05.05, Ubuntu 16.04.3 LTS, Perl v5.22.1 gather_print_notices.pl run from cron (sudo crontab -e) would fail with this error: Can't locate Koha/Exceptions/Exception.pm: ./Koha/Exceptions/Exception.pm: Permission denied at /usr/share/perl/5.22/base.pm line 97. ...propagated at /usr/share/perl/5.22/base.pm line 106. BEGIN failed--compilation aborted at (eval 14) line 3. BEGIN failed--compilation aborted at /usr/share/koha/lib/Koha/Exceptions.pm line 56. Compilation failed in require at /usr/share/koha/lib/Koha/DateUtils.pm line 22. BEGIN failed--compilation aborted at /usr/share/koha/lib/Koha/DateUtils.pm line 22. Compilation failed in require at /usr/share/koha/lib/C4/Log.pm line 30. BEGIN failed--compilation aborted at /usr/share/koha/lib/C4/Log.pm line 30. Compilation failed in require at /usr/share/koha/lib/Koha/Config/SysPref.pm line 26. BEGIN failed--compilation aborted at /usr/share/koha/lib/Koha/Config/SysPref.pm line 26. Compilation failed in require at /usr/share/koha/lib/C4/Context.pm line 105. BEGIN failed--compilation aborted at /usr/share/koha/lib/C4/Context.pm line 105. Compilation failed in require at /usr/share/koha/bin/cronjobs/gather_print_notices.pl line 13. BEGIN failed--compilation aborted at /usr/share/koha/bin/cronjobs/gather_print_notices.pl line 13. Running the command in the crontab on the command line would succeed, no errors. Adding the "cd /tmp &&" trick in front of the commands in the crontab makes the errors go away. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #46 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- It looks like this one is not dead yet - Tomas, could you take another look as you hunted down the problem last time? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #48 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Marco Moreno from comment #47)

Understanding the problem is necessary to determine the best solution. [...] 5. Change the current directory to one that is readable by modifying all code that performs a "sudo -u". This may be as simple as adding "cd /tmp" at the beginning of /usr/sbin/koha-foreach and /usr/sbin/koha-rebuild-zebra. Possibly the best solution for now.

Option #5 seems like the best one for now. It is a clear, one-line solution that doesn't require modifying any crons.

I would agree. Put cd /tmp very close to the sudo -u. Adding it in cron is more confusing. Clear argumentation imo! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEW --- Comment #50 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Can anyone take care of this one? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|chris@bigballofwax.co.nz |tomascohen@gmail.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #52 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Marcel de Rooy from comment #48)

(In reply to Marco Moreno from comment #47)

...

Understanding the problem is necessary to determine the best solution. [...] 5. Change the current directory to one that is readable by modifying all code that performs a "sudo -u". This may be as simple as adding "cd /tmp" at the beginning of /usr/sbin/koha-foreach and /usr/sbin/koha-rebuild-zebra. Possibly the best solution for now.

Option #5 seems like the best one for now. It is a clear, one-line solution that doesn't require modifying any crons.

I would agree. Put cd /tmp very close to the sudo -u. Adding it in cron is more confusing. Clear argumentation imo!

If there's a /tmp/Koha directory, without read permissions for the instance's user it will still fail. I think we should jump into the instance's home directory and I'm providing a patch to do so. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #54 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 72369 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=72369&action=edit Bug 17717: Make cronjobs using koha-foreach use --chdir In order to patch production sites we need to adjust the shipped cronjobs so they are called with the --chdir option switch. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|process_message_queue.pl: |Fix broken cronjobs due to |Can't locate |permissions of the current |Authen/CAS/Client/Response/ |directory |Failure.pm | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #72368|0 |1 is obsolete| | Attachment #72369|0 |1 is obsolete| | --- Comment #55 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 72372 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=72372&action=edit Bug 17717: Add a --chdir option switch for koha-foreach Until Perl 5.26, the current directory is added to @INC when running a Perl script [1]. Having the current directory in @INC means it can be tried to be traversed when performing a lib lookup. Since version 5.18, Perl dies when it finds an unreadable directory (permissions) in @INC that needs to be traversed. This behaviour won't change because Perl devs consider it an enhancement to security. [2] Because of this, we need to make sure our scripts are ran **from** a directory in which they have read permissions. Ths patch adds a --chdir option switch to the **koha-foreach** wrapper script, that makes the inner shells/scripts to be ran within the Koha instance's user home directory. The change is trivial and should be QAed easily. I tested this on a prod server: - Create a /tmp/test.pl file containing: use Modern::Perl; use Cwd; my $dir = getcwd; warn $dir; 1; A) then create a cronjob entry to run it using koha-foreach: (in /etc/cron.d/test): 1/* * * * * root koha-foreach perl /tmp/test.pl - Once I noticed the cronjob ran, I used mutt to read the emails in the root user. => FAIL: ... Subject: Cron <root@koha> koha-foreach --enabled perl /tmp/test.pl "/root" "/root" "/root" "/root" "/root" ... B) I then used the patched koha-foreach with different results: => SUCCESS: ... Subject: Cron <root@koha> /root/koha-foreach --chdir --enabled perl /tmp/test.pl "/var/lib/koha/acaderc" "/var/lib/koha/agro" "/var/lib/koha/anc" "/var/lib/koha/arico" "/var/lib/koha/artes" ... So this patch's approach works. But... C) master's koha-foreach seems to work just the same... I think it is because of my previous attempt to fix this by using sudo in koha-shell. So I think environmental conditions affect the behaviour (which shell is configured for cron, sudo configuration, etc). ==== In conclusion, I think we should go ahead with this patch as it will solve peoples issues, and it is a right solution (option #5 on the list) to this Perl behaviour change. It doesn't cover other commands, but followup patches could do. I avoided /tmp as it is writable by any user... so it is an easy path for both exploiting by replacing some lib, and also because the existence of an unreadable dir that the interpreter could try to traverse (unreadable /tmp/Authen or /tmp/Koha will trigger the same error, and I assume people know what they are putting on the instance's dir, at least it will be easier to track). A followup patch takes care of making the cronjobs use --chdir when calling koha-foreach [1] https://lists.debian.org/debian-devel-announce/2016/08/msg00013.html [2] https://rt.perl.org/Public/Bug/Display.html?id=123795 Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #57 from Marco Moreno <mmoreno@pobox.com> --- Hmmm...I'm now reconsidering this and wonder if option #3 is really the best solution by removing '.' from @INC. You made a good point about /tmp being a concern. This, plus the fact that they have removed '.' from @INC in recent versions of Perl, has convinced me that having '.' in @INC is generally a very bad idea and a major security concern. Therefore, I want to propose revisiting comment #40 which removes '.' from @INC in a common library early in the bootstrapping process. This effectively undoes the "feature" added in Perl 5.18 and removed in Perl 5.26. Additionally, this prevents exploits that attempt to insert '.' via PERL5LIB. It is a single line of code, does nothing if '.' doesn't exist in @INC, and doesn't require modifying crons. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #59 from Marco Moreno <mmoreno@pobox.com> --- Couldn't it be done in once in a common library that is used everywhere, like /usr/share/koha/bin/kohalib.pl? Sorry, I really don't know much about Koha's architecture and I trust you've studied this more than I have. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #61 from Marco Moreno <mmoreno@pobox.com> --- Fair enough - trust your judgment. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=19546 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #72372|0 |1 is obsolete| | --- Comment #63 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 72411 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=72411&action=edit Bug 17717: Add a --chdir option switch for koha-foreach Until Perl 5.26, the current directory is added to @INC when running a Perl script [1]. Having the current directory in @INC means it can be tried to be traversed when performing a lib lookup. Since version 5.18, Perl dies when it finds an unreadable directory (permissions) in @INC that needs to be traversed. This behaviour won't change because Perl devs consider it an enhancement to security. [2] Because of this, we need to make sure our scripts are ran **from** a directory in which they have read permissions. Ths patch adds a --chdir option switch to the **koha-foreach** wrapper script, that makes the inner shells/scripts to be ran within the Koha instance's user home directory. The change is trivial and should be QAed easily. I tested this on a prod server: - Create a /tmp/test.pl file containing: use Modern::Perl; use Cwd; my $dir = getcwd; warn $dir; 1; A) then create a cronjob entry to run it using koha-foreach: (in /etc/cron.d/test): 1/* * * * * root koha-foreach perl /tmp/test.pl - Once I noticed the cronjob ran, I used mutt to read the emails in the root user. => FAIL: ... Subject: Cron <root@koha> koha-foreach --enabled perl /tmp/test.pl "/root" "/root" "/root" "/root" "/root" ... B) I then used the patched koha-foreach with different results: => SUCCESS: ... Subject: Cron <root@koha> /root/koha-foreach --chdir --enabled perl /tmp/test.pl "/var/lib/koha/acaderc" "/var/lib/koha/agro" "/var/lib/koha/anc" "/var/lib/koha/arico" "/var/lib/koha/artes" ... So this patch's approach works. But... C) master's koha-foreach seems to work just the same... I think it is because of my previous attempt to fix this by using sudo in koha-shell. So I think environmental conditions affect the behaviour (which shell is configured for cron, sudo configuration, etc). ==== In conclusion, I think we should go ahead with this patch as it will solve peoples issues, and it is a right solution (option #5 on the list) to this Perl behaviour change. It doesn't cover other commands, but followup patches could do. I avoided /tmp as it is writable by any user... so it is an easy path for both exploiting by replacing some lib, and also because the existence of an unreadable dir that the interpreter could try to traverse (unreadable /tmp/Authen or /tmp/Koha will trigger the same error, and I assume people know what they are putting on the instance's dir, at least it will be easier to track). A followup patch takes care of making the cronjobs use --chdir when calling koha-foreach [1] https://lists.debian.org/debian-devel-announce/2016/08/msg00013.html [2] https://rt.perl.org/Public/Bug/Display.html?id=123795 Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 --- Comment #65 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 72413 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=72413&action=edit Bug 17717: (QA follow-up) Fix typo chdir This test does obviously not achieve the desired result: [ "chdir" != "no" ] Trivial fix. Adding the same quotes around starting_dir (just as for Bug 19546). Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@bywatersolutions.com Status|Passed QA |Pushed to Master --- Comment #66 from Nick Clemens <nick@bywatersolutions.com> --- Pushed to master for 18.05, thanks to all for your hard work. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to Master |Pushed to Stable --- Comment #67 from Nick Clemens <nick@bywatersolutions.com> --- Awesome work all, backported to stable for 17.11.05 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|Pushed to Stable |RESOLVED CC| |martin.renvoize@ptfs-europe | |.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Nitesh Kumar Verma <vermanite@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Ever confirmed|1 |0 Status|CLOSED |UNCONFIRMED CC| |vermanite@gmail.com --- Comment #70 from Nitesh Kumar Verma <vermanite@gmail.com> --- Facing the same problem in my KOHA version 16.11. While trying to apply the said patch, I am not able to find the file 'koha-foreach.xml'. Guide me to find the file koha-foreach.xml so that may apply the patch. Regards, Dr. Nitesh Kumar Verma -- You are receiving this mail because: You are watching all bug changes.