6

"Private /tmp is just like a good idea... it worked for me, it is more safe, so let's redistribute to every unix-man in the world that expects /tmp is /tmp since 1970..." What do you get? Explosion, destruction and your body on fire.

I am trying to disable private /tmp on Debian 9, so I followed the instructions from this site:

https://www.maxoberberger.net/blog/2017/10/debian-9-private-tmp.html

It seems pretty nice, but it is not, and it is causing some heartache.

When I tried to disable by creating an override file on /etc/systemd/system/apache2.service, systemd seems to ignore me completely.

I need to edit the file directly in: 

/lib/systemd/system/apache2.service

That works, but that is not really a good idea specially if you upgrade your system! Today, unattended-upgrade ran and everything is broken because of private tmp; then I needed to re-disable it again. We use a web system that communicates with another old system that runs on the console ... it communicates via tmp.

What I am doing wrong? Should I restart the server?

Improve this question
1
  • Good morning and thank you for including all these details :). Only one nitpick: it would be great if you would include all the steps you took, inside the question, i.e. restarting apache. In case the blog author fixes their article, it will be confusing to read this question in future. But thanks for including the link, in general I really like being able to see why the asker expected what they did to work :). Commented Jun 5, 2018 at 19:23

1 Answer 1

Reset to default
5

It is missing the step systemctl daemon-reload, to reload the systemd unit file. Do this first, then restart the service

Rebooting the server as a whole would also work, but it is not necessary.

P.S. if you had the same problem as the linked article, with apache wanting to read some files written by a cronjob, you could address this in a more fine-grained way by... not using /tmp for those files. You might be able to configure a directory which is writable by the cronjob, without having to worry about the security problems that come from working with /tmp. I.e. where another UID might be able to steal your hardcoded socket name / subdirectory in /tmp before your desired process can reserve it.

Improve this answer
1
  • 1
    Yes everything was working, but to avoid all this problem, I just migrated to Devuan. See my profile to see more informations. Commented Mar 21, 2019 at 20:37

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.