The latest victim of systemd's PrivateTmp…

[Sam Varshavchik]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20130114/11be36fd/attachment.sig>