The latest victim of systemd's PrivateTmp…

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/14/2013 09:57 PM, Sam Varshavchik wrote:
> Rick Stevens writes:
> 
>> On 01/14/2013 05:38 PM, Sam Varshavchik issued this missive:
>>> Rick Stevens writes:
>>> 
>>>> On 01/14/2013 05:15 PM, Sam Varshavchik issued this missive:
>>>>> Tom Horsley writes:
>>>>> 
>>>>>> On Mon, 14 Jan 2013 08:32:19 -0500 Sam Varshavchik wrote:
>>>>>> 
>>>>>>> … appears to be Apache. After installing the most recent
>>>>>> systemd update:
>>>>>>> 
>>>>>>> systemd[1429]: Failed at step NAMESPACE spawning
>>>>>>> /usr/sbin/httpd:
>>>>>> Operation
>>>>>>> not permitted
>>>>>> 
>>>>>> I just installed updates (and rebooted) this morning and apache
>>>>>> seems to be running fine on my desktop. I've got
>>>>>> systemd-44-23.fc17.x86_64
>>>>> 
>>>>> Yeah, some of my other machines seems to have survived. But all I
>>>>> know, is that on a stripped down, headless box, this update broke
>>>>> Apache, until I took out PrivateTmp out of httpd.service. Only
>>>>> systemd was updated, apache wasn't. That's all I can figure out for
>>>>> now. The error message text wasn't very helpful, and googling it
>>>>> around found a bunch of references to PrivateTmp, so I took it out,
>>>>> and systemctl start httpd.service worked. Put it back, systemd
>>>>> refuses to start it, take it out, it works.
>>>> 
>>>> Did you check to see if you have any selinux log entries pertaining
>>>> to this? "Operation not permitted" smells selinux-ishy to me.
>>> 
>>> This stripped down box does not use selinux.
>>> 
>>> Jan 14 06:54:40 shorty kernel: [    3.219771] SELinux:  Disabled at 
>>> runtime. Jan 14 06:54:40 shorty kernel: [    3.249018] type=1404 
>>> audit(1358164472.135:2): selinux=0 auid=4294967295 ses=4294967295
>>> 
>>> /etc/selinux/config has SELINUX=disabled
>>> 
>>> The only thing that comes to mind that I have non-standard is:
>>> 
>>> [root at shorty ~]# ls -al /var/www lrwxrwxrwx. 1 root root 11 Apr 19
>>> 2011 /var/www -> ../home/www
>>> 
>>> But if this caused some unfathomable problem with systemd's
>>> PrivateTmp, I'd expect apache to barf, instead of systemd whining.
>> 
>> That isn't a broken link, is it, or some permissions issue where systemd
>> (or Apache) doesn't have access to /home/www? I can see /var/www being a
>> symlink to /home/<someuser>/www or even /home/www, but does the apache
>> user have write access to it?
> 
> As I wrote before: after disabling PrivateTmp for httpd.service, Apache
> comes up just fine.
> 
> It would quite an impressive accomplishment if the presence of PrivateTmp 
> directive in httpd.service would somehow break and unbreak, repeatedly, a 
> symlink somewhere else in the filesystem.
> 
> Furthermore, if, somehow were that to be the case, everything that I've
> ever learned about Unix or Linux tells me that it would be apache crapping
> all over my syslog, instead of systemd.
> 
> 
> 
> 


What might be happening is the ability for the container to see mount points
from the host system.

If you run

mount --make-rshared /

Before starting the apache service with the PrivateTmp, does the apache server
work?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlD1flcACgkQrlYvE4MpobNUiwCg0p/0ec8JOF4Z2baunOvM0/Ig
FjYAoI8kdxrd1A2lM0yDGTztj7nEoIhQ
=FqJg
-----END PGP SIGNATURE-----