Fedora reported a security issue:
there is a new security flaw affecting Zarafa. It did not walk over the
mailing lists so far, however it is public. Details and patch are here:
This has been resolved in version 7.1.13
We dropped it in mga5 but we still have versions 7.1.11 in mga
I will update this package as soon as the source will be available.
Steps to Reproduce:
Zarafa fixed this issue with version 7.2.1 beta 1, however they unfortunately
did not release any source code files nor a source code patch so far. At
https://download.zarafa.com/community/beta/7.2/7.2.1-49597/ the "sourcecode"
directory is missing.
Meanwhile Zarafa has published the source code of Zarafa 7.2.1 beta 1
This bug has been resolved by upgrading to ver. 7.1.12 and attaching a patch made by Fedora from the Relevant difference between Zarafa 7.2.0 and 7.2.1 beta 1
The following files are in updates_testing:
and corresponding i586 packages
assigning it to qa
RedHat description for this is:
Guido GÃ¼nther detected and reported that replacing "/tmp/zarafa-upgrade-lock"
by a symlink makes the zarafa-server process following that symlink and thus
allows to overwrite arbitrary files in the filesystem (assuming zarafa-server
runs as root which is not case by default at Fedora, but upstream default).
One just needs write permissions in /tmp and wait until the zarafa-server is
First of all, we have protected_symlinks so it will not follow a symlink if you make one, second of all, I'm guessing if Fedora's package doesn't run as root, ours doesn't either. So this would just be a minor bugfix for us. Do we know what impact it has on our package if someone creates that symlink?
I am not even sure anybody uses the Mageia package.We had no bug reports when it didn't run.
(In reply to David Walser from comment #3)
> First of all, we have protected_symlinks so it will not follow a symlink if
> you make one, second of all, I'm guessing if Fedora's package doesn't run as
> root, ours doesn't either. So this would just be a minor bugfix for us. Do
> we know what impact it has on our package if someone creates that symlink?
You can verify this using "grep ^run_as_ /etc/zarafa/*.cfg", according to
https://svnweb.mageia.org/packages/updates/4/zarafa/current/SPECS/zarafa.spec?view=annotate the daemons are not running as root since at least subversion
rev. 62086 (if that helps), which seems to be the initial import into Mageia.
MGA4-32 on AcerD620 Xfce.
Confirm that zarafa is running as user zarafa as per Comment 5 above.
On installation, found no zarafa-debuginfo package, but that should not be a stopper?
Applied change in /etc/zarafa/server.cfg as per bug14993, and chacked that /etc/httpd/conf/sites.d/zarafa-webaccess.conf has per bug14993 Comment16
Then as root
>systemctl start zarafa-server , returns nothing
> systemctl status -l zarafa-server
zarafa-server.service - LSB: Zarafa Collaboration Platform's Storage Server
Loaded: loaded (/etc/rc.d/init.d/zarafa-server)
Active: active (running) since ma 2015-06-08 14:49:28 CEST; 4s ago
Process: 3289 ExecStart=/etc/rc.d/init.d/zarafa-server start (code=exited, status=0/SUCCESS)
Main PID: 3302 (zarafa-server)
ââ3302 /usr/bin/zarafa-server -c /etc/zarafa/server.cfg
jun 08 14:49:28 mach6.hviaene.thuis systemd: Starting LSB: Zarafa Collaboration Platform's Storage Server...
jun 08 14:49:28 mach6.hviaene.thuis zarafa-server: Starting zarafa-server: [ OK ]
jun 08 14:49:28 mach6.hviaene.thuis systemd: Started LSB: Zarafa Collaboration Platform's Storage Server.
and browsing to http://localhost/webaccess gives zarafa-webacces logon page
MGA4-64 on HP-Probook 6555b.
Confirm results as per Comment 6 above.
has_procedure MGA4-64-OK MGA4-32-OK
Fedora has issued an advisory for this on May 19:
Validating. Advisory uploaded.
Please push to 4 updates
has_procedure MGA4-64-OK MGA4-32-OK =>
has_procedure advisory MGA4-64-OK MGA4-32-OKCC:
An update for this issue has been pushed to Mageia Updates repository.