Disable Logs for maximum privacy

Linux Support
1

How to put directories like /tmp, /var/tmp, /var/log (especially logs!) in tmpfs to enchance privacy?

ALL logs, including system ones and journald… I think 50Mb in RAM for them will be enough? Or maybe use sledgehammer method and redirect them to /dev/null?

I need to reduce anything that can be used to track how i used my laptop. I understand risk that this can make troubleshooting harder.

I have 16gb of RAM. And I use it pretty much.

So if putting logs to RAM is bad for performance maybe in /dev/null (won’t constant use of dev/null harm SSD?)? But I need not to break anything in system. And yes, I am okay with headache with troubleshooting. This is tradeoff for maximum privacy if unauthorized access.

How to do so? Can you please help for both versions (tmpfs and /dev/null)?

1 Like
2

it’s not good idea to use memory, to temporary save logs once you shut down your machine all the logs will be lost

do it at your own risk (not safe)

-rf the log dir
use fstab tmpfs /var/log tmpfs nosuid,nodev,noatime 0 0

Better option is to encrypted it, not worthy because all logs are technical stuff doesn’t necessary include file names / text or any data.

1 Like
3

Hi @lamehen welcome to the Linux Community!

You can mount /var/log, /tmp, and /var/tmp as tmpfs via /etc/fstab. That keeps logs in RAM and wipes them on reboot. Example:

tmpfs /var/log tmpfs defaults,noatime,nosuid,nodev,mode=0755,size=50M 0 0
tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,size=100M 0 0

Then use a boot script to recreate needed dirs (/var/log/journal, etc.) or some stuff will break. For journald, set Storage=volatile in journald.conf.

If you’re okay with breaking some logging tools completely, symlink key logs to /dev/null:

ln -sf /dev/null /var/log/syslog
ln -sf /dev/null /var/log/auth.log

Also set Storage=none in journald. Just know some apps might crash or silently fail if they rely on those files existing.

You won’t hurt your SSD with /dev/null — that’s RAM. But writing logs to disk constantly does wear SSDs over time, so your method helps with that too. Wear is no longer a concern with NVMe storage. Mostly it’s with SD cards and older SSDs

If it were me: tmpfs + Storage=volatile gives a good balance between privacy and not totally nuking logging. :smile:

3 Likes
4

very good explanation @hydn
it would be worth a blog post, right?

5

Thanks! I probably wouldn’t. Not from the privacy standpoint at least. But I would consider writing about it from the angle of reducing disk writes caused by excessive logging. If you’d like, you can write an article for a feature on the blog. Blog posts also get sent out on Mondays’s to fellow tech guru newsletter subscribers.

As for this reduction in logging. I’ve seen web servers that handle millions of users per hour take some performance hit due to logs flooding the disk with hundreds of millions of lines in a short period, especially when you combine system, service, and application logs.

Logging isn’t usually a big issue for most setups, but on very busy servers it can be. Once in production, it often makes sense to reduce log levels from notice or warning to just error and critical to avoid unnecessary disk I/O. Even things like Nginx access logs combined with other similar session logging can get crazy. A simple deprecated warning from an app or from the service stack about a feature can result in so many logs that it’s sometimes fills up servers’ storage space.

On desktops, maybe it’s a privacy concern for some—but personally, that’s not my focus.

There is a related blog post that touches on this:

1 Like
6

Like this?

tmpfs /var/log tmpfs defaults,noatime,nosuid,nodev,mode=0755,size=50M 0 0
tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,size=700M 0 0
tmpfs /var/tmp tmpfs defaults,noatime,nosuid,nodev,mode=0755,size=500M 0 0

Is it enough space not to break anything? And will it persist after reboot?

I think this is better too. Because silenced logs not really help with troubleshooting.

By the way, do you think it is better to add “noatime” flag to all disks?

I think yes.

Two reasons:

  1. Privacy reasons with hardware security (because deleted from flash can be possible restored, from RAM - almost impossible) which is my case
  2. Flash life increasing (as said, SD and old SSD can live longer if writes will be decreased)

Personally, I think that less on disk = better. First it is faster (RAM faster than even fastest SSD), secondly it is more private (if sized for example), and for the end, it is increasing lifespan for SSD.

So SWAP, Logs, TMP folders etc should be put in RAM or if RAM is not sufficient to /dev/null at least for better performance and privacy.

P.S: I think the idea of so high privacy as I need won’t be needed by most people, so they should use RAM less aggressively, just to increase performance.

1 Like