[CentOS] systemd private tmp dirs

[Les Mikesell]

On Wed, Apr 15, 2015 at 5:01 PM, Matthew Miller <mattdm at mattdm.org> wrote:
> On Wed, Apr 15, 2015 at 04:15:23PM -0500, Les Mikesell wrote:
>> > Why does this directory have to be /tmp rather than a specific
>> > directory belonging to twiki?
>> Twiki is a perl web application run under apache.  It doesn't have its
>> own uid.  It doesn't 'have' to be anywhere in particular but that is
>> the way it was written and thus has very confusing results when trying
>> to move it to CentOS 7.  Is there some generic approach to fixing this
>> kind of breakage (that is, to make it work and not confusing, not to
>> say it was broken as designed)?    To function as a backup, it
>> probably shouldn't default to being in the same directory as the files
>> it backs up.
>
> There are two (sane) options, I think.
>
> The first, and I think the best, is to configure twiki to share files
> in some specific location rather than /tmp. It doesn't have to be the
> same directory as the files being backed up — maybe something under
> /var/lib/twiki (or /var/local/twiki).
>
> If the twiki backup plugin didn't allow this to be configured, I would
> argue that it _is_ broken by design. But a quick Google search leads me
> to <http://twiki.org/cgi-bin/view/Plugins/BackupRestorePlugin>, which
> shows that it is indeed configurable, so I'm just going to call it a
> questionable default. :)
>
> If you want to keep that default, though, the second approach would be
> to configure Apache to not use a private namespace, which I don't
> recommend because you lose the security benefit. To do that, put
>
> [Service]
> PrivateTmp=false
>
> in /etc/systemd/system/httpd.service (which may not exist).
>

Thanks - I can see how those would work once you understand what is
broken on the target system and why, but is there a way that programs
'should' be written to run with/without systemd?   That just happened
to be the first thing I've tried to move over that wasn't already
packaged and adapted - I expect to hit many more.

-- 
   Les Mikesell
     lesmikesell at gmail.com