Security Hardening: change /tmp path during diet-update

Hi everyone,

thanks for let me be part of the community - this is my first post here hello everyone. Thanks DietPi-Team for making such a great project!

I am currently building a dedicated VPN Server with WireGuard. To maximise security I found this guide (, which refers to the CIS Benchmarks for Debian 9.

I went trough all those steps, to fully understand the guide, I think there are some pretty nice recommendations. One step is about modifying the /etc/fstab.
It is recommended in this guide to set the noexec option for the /tmp path.

tmpfs /tmp tmpfs defaults,size=1023M,strictatime,noexec,nodev,nosuid,mode=1777 0 0

Until that point I didn’t even recognise that diet-update is using the /tmp and modifies execution permission ( (line 291), which was no longer possible.

Regarding the CIS Benchmark( this is a scored issue.

I am not really into linux security but from my perspective this is a really nice idea for a device which sits behind and open port and can well take a little security.

Is it possible to manually change the path for diet-update or will this every time be reversed when major update occur?


PS: I am also considering to install firewalld. To to be honest I am not really sure if this will improve this security that much, since I am dependent on the security of the routers firewall… any thoughts?

/tmp is basically used on DietPi scripts which will do software installations. Basically dietpi-update and dietpi-software. The usage of /tmp is hardcode into our scripts, nothing you can change on the fly. It might be ok to use noexec option, if you don’t aim to install software title from out catalogue.


thanks for the recommendation! I am using dietpi mainly because of the build in tools. But I might consider this if I am “ready” with the server.
good to know that the path it’s hard coded and not worth trying to change.

There are not many but some cases where temporary executables are executed from /tmp during dietpi-software installs as well. Not sure about the benefits of noexec on /tmp. It is world-writable but any user/attacker could just write or download and execute anything from the controlled user’s home directory. Everything sensitive it applied strict permissions in the first place or is created within a systemd sandbox sub directory (those dirs in /tmp with the long names). It is also not explicitly part of the CIS benchmark TOC, but mentioned only related to making /tmp a dedicated filesystem only (a filesystem, not a partition :wink:).

We definitely want to be able to keep temporary executables in RAM instead of having to write them to disk, during updates and installs. And I’m not keen to create a dedicated tmpfs only for our scripts, when there is already one exactly aimed to be used for temporary files. The noexec flag AFAIK cannot be unset for a subdirectory, of course it could be unset and reset via mount -o remount,exec/mount -o remount,noexec, ondemand. Not sure whether its worth it to implement a noxec steck and in case remount :thinking:. If anyone has an idea or opinion on this, please let us know :slight_smile:.