That's a URL, not a bug report!  The feature page talks about a choice between changing the systemd default or changing all the service files, but it does not mention what decision has been made.   Nor does it document specifically what I should to the .service files, which would have saved a few minutes of my time.

I am presuming "PrivateTmp=true" in the [service] section is correct, and that the systemd default is not to be changed.

-> in httpd-2.2.21-6.fc17

Sorry, Joe. I don't think we are ready to turn it on by default, since it just started working well.  I think if we get a few of the more dangerous apps to run ok with this change, then we can maybe think about changing the default in F18.

For the record, this seems to break rutorrent (PHP UI for rtorrent, http://code.google.com/p/rutorrent/ ), as it tries to communicate with another process using /tmp (it requests rtorrent to run some shell commands via xmlrpc that write to /tmp and then it tries to read them back in PHP code).

That is trivially workaroundable (if the user figures out what is wrong, that is) by modifying the code to use some other directory instead, though.

Anyway, I can't say whether the benefit of PrivateTmp outweighs some web applications breaking, this is just to note that there is at least one such webapp which is affected.

Is it communicating with a user process?  What other process is it attempting to communicate with.  Can we open a bug with rutorrent to use /var/run for its communications by default.

Yes, with a quick look it seems to use the rTorrent XMLRPC command 'execute' to e.g. run some shell commands that write to '/tmp' that the PHP code then reads. And the rTorrent process is generally running as a normal user.

A quick grep for /tmp in the rutorrent-3.4.tar.gz and plugins-3.4.tar.gz shows it is in some way used in 18 files, and without looking closely it seems many of those are similar cases (i.e. XMLRPC-calling rTorrent to write to some tmp file and then read it back in PHP, possibly in the other direction as well).

I guess a bug could be opened (they have a bugtracker at http://code.google.com/p/rutorrent/issues/list ).

Looks to me like the cases could be fixed to just use the rTorrent XMLRPC interface to return the data instead of using the '/tmp' hack, rTorrent seems to have e.g. 'execute.capture' command for this purpose...

^^ This.  It took me 2 days to try and understand why Apache wouldn't read files in /tmp.

Dan, I noticed that with PrivateTmp enabled, a running httpd process does not pick up new mounts - it's a separate fs namespace or something?  This is surprising behaviour, is it a bug or a feature?

I would say this is a bug.  We should setup the PrivateTmp to see parent changes except for /tmp directories.

I think this is why we used to have the sandbox init script, that does

  mount --make-rshared / 

Try executing this command before starting apache and see if changes to / get reflected within the apache namespace.

# mount --make-rshared / 

yup, that works.  Are you going to file a bug against the appropriate component, or should I?  (systemd?)

I think we have to bring this up with systemd.  We had a long talks about this a couple of years ago, and we wanted to get these calls into the fstab.  But the mount/kernel guys disagreed. I guess we should talk to Lennart if it is best that he calls it before he starts the first PrivTmp.

I got a lot of complaints when I just had the service.

Maybe we have a service that is triggered sharedroot.service that executes this command once.

https://bugzilla.redhat.com/show_bug.cgi?id=712089

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.