(U)Mounting through "exec" with "sudo". The user is a "sudoer" with NOPASSWD

Question 1

It was the Apache's corresponding systemd service, that had PrivateTmp=true directive. Apparently, the directive executes the process with a new file system namespace.

This question, while attempting to debug and fix the issue spawned a numerous other posts around the internet.

Each derived from stuff I've learn in the process.

I started with getting deeper information about mount working on EUID. Soon, I found out that my simple sudo call is actually not executing with EUID 0. That led me to multiple queries on how to do so, that in return spawned command syntax like sudo -i 'su' -c 'mount /dev/sdb1 /mnt/firstone' and other derivatives.

Having no success with the solution, I looked further.

I started to think of trying to add the entry to /etc/fstab, that led me to loads of permission issues. Also, sudo and my CLI tool proved to be incomplete for the task. Lets bring the big weapons - lets compile Apache with -DBIG_SECURITY_HOLE, also known as, give Apache the possibility to be run as root.

Lets append entry to the tab, lets attempt to mount... and... fail!

After numerous tests, queries and what not, I stumbled upon per process mount that led me here and opened the dimension of namespaces to me.

Okay, that explains everything - checking /proc/<pid>/mounts validates it, now, lets gnaw deeper and see how to overcome it.

Again, after numerous attempts and no success, I started posting questions based around my fresh knowledge of namespaces. Narrowing the questions down and becoming more technical (at least I think I did), that eventually led to a user hiciu who pointed me into systemd direction, specifically, Apaches service - PrivateTmp.

Voila! ...apparently systemd can enforce new namespaces.

Question 2

I had the same strange behavior of apache and spent more than 3 days without any working solution. Then luckyly I found this post and as you described PrivateTmp caused the issue. In my case, I tried to mount a drive from php:

<?php
...
exec("sudo mount /dev/sda1 /mnt/drive", $output, $ret);
...
?>

When I ran above code from web browser, exec function return 0 (success) and I was even abble to list thru mapped drive within the code:

exec("ls /mnt/drive", $o, $r);
foreach ($o as $line){
  echo $line.'<BR>';
}

But when I tried search for mapped drive from cli, I cannot see it. I tried everything, include change permissions, change php.ini etc. Nothing help. Until now, changing

PrivateTmp=false

in

/lib/systemd/system/apache2.service

does the trick. Thank you very much for sharing!

Question 3

It was searching for this and is looks like this behavior is implemented and detectable from php via chroot:

 system('ischroot;echo $?');

gives 0 with the setting PrivateTmp=true (saying 'you are in a chroot') and 1 with PrivateTemp=false.

(U)Mounting through "exec" with "sudo". The user is a "sudoer" with NOPASSWD

Environment

Problem

Update (2013-10-28)

Question