+++ This bug was initially created as a clone of Bug #1169238


This function rejects relative path components in the target mount path,
unlike its sibbling function described in b). However, it is unaware of
symlinks. Furthermore it makes sure that /media/$user and /media/$user/sub are
existing and are owned by the $uid:$gid of the unprivileged user.

- by placing a symlink in /media/$user/sub the setuid-root binary can be
  tricked to create attacker owned directories in arbitrary locations.
  This can quite likely lead to full root access by creating user owned
  directories e.g. beneath /etc that are then used by other privileged
  programs.
- if the attacker wins a race condition he can also cause the setuid-root
  binary to pass ownership of arbitrary existing directories to himself. The
  `_store_mount_verify()` functions performs a single `stat()` call on the
  target mount path. Only if it exists and is not owned by the unprivileged
  user, the execution is aborted. Therefore if the attacker places a suitable
  symlink in the target path just after this `stat()` is performed by the
  setuid-root binary, the following `_mkdir()` invocation will `mkdir()` and
  `chown()` the path components nonetheless. This allows full root system
  access by gaining ownership of e.g. /etc or /root.

To fix this I suggest not to pass ownership of /media/$user or of any
sub-directories to the unprivileged user. If /media/$user is user controlled
then the mount operation should be rejected.