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:
zarafa-7.1.12-1.mga4.src.rpm
zarafa-7.1.12-1.mga4.x86_64.rpm
zarafa-client-7.1.12-1.mga4.x86_64.rpm
zarafa-common-7.1.12-1.mga4.x86_64.rpm
zarafa-dagent-7.1.12-1.mga4.x86_64.rpm
lib64zarafa-devel-7.1.12-1.mga4.x86_64.rpm
zarafa-gateway-7.1.12-1.mga4.x86_64.rpm
zarafa-ical-7.1.12-1.mga4.x86_64.rpm
zarafa-caldav-7.1.12-1.mga4.x86_64.rpm
zarafa-monitor-7.1.12-1.mga4.x86_64.rpm
zarafa-server-7.1.12-1.mga4.x86_64.rpm
zarafa-spooler-7.1.12-1.mga4.x86_64.rpm
zarafa-utils-7.1.12-1.mga4.x86_64.rpm
lib64zarafa0-7.1.12-1.mga4.x86_64.rpm
python-MAPI-7.1.12-1.mga4.x86_64.rpm
php-mapi-7.1.12-1.mga4.x86_64.rpm
zarafa-indexer-7.1.12-1.mga4.x86_64.rpm
zarafa-webaccess-7.1.12-1.mga4.noarch.rpm
zarafa-archiver-7.1.12-1.mga4.x86_64.rpm
zarafa-debuginfo-7.1.12-1.mga4.x86_64.rpm
and corresponding i586 packages

CC: (none) => thomas

assigning it to qa

Assignee: thomas => qa-bugs
Source RPM: zarafa-7.1.1 => zarafa-7.1.11

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
restarted.

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?

Priority: High => Normal
Severity: major => normal

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
and
> 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)
   CGroup: /system.slice/zarafa-server.service
           ââ3302 /usr/bin/zarafa-server -c /etc/zarafa/server.cfg

jun 08 14:49:28 mach6.hviaene.thuis systemd[1]: Starting LSB: Zarafa Collaboration Platform's Storage Server...
jun 08 14:49:28 mach6.hviaene.thuis zarafa-server[3289]: Starting zarafa-server: [  OK  ]
jun 08 14:49:28 mach6.hviaene.thuis systemd[1]: Started LSB: Zarafa Collaboration Platform's Storage Server.
and browsing to http://localhost/webaccess gives zarafa-webacces logon page

CC: (none) => herman.viaene
Whiteboard: (none) => MGA4-32-OK

MGA4-64 on HP-Probook 6555b.
Confirm results as per Comment 6 above.

Whiteboard: MGA4-32-OK => has_procedure MGA4-64-OK MGA4-32-OK

Fedora has issued an advisory for this on May 19:
https://lists.fedoraproject.org/pipermail/package-announce/2015-June/159497.html

URL: (none) => http://lwn.net/Vulnerabilities/647496/

Validating. Advisory uploaded.

Please push to 4 updates

Thanks!

Keywords: (none) => validated_update
Whiteboard: has_procedure MGA4-64-OK MGA4-32-OK => has_procedure advisory MGA4-64-OK MGA4-32-OK
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGAA-2015-0054.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED