Mounting thumbnails to tmpfs

Thumbnails are turned off by default in Workstation. Would it be a good idea to mount all thumbnails to a tmpfs directory stored in RAM? Thumbnails rarely add up in significant size - I’ve generated up to 10,000 before and it barely took 1 GB. Would an entry in fstab like the following be ideal, or are there security risks in doing so?:

none /home/[username]/.thumbnails tmpfs rw,noexec,nosuid,size=20%,uid=1000,gid=1000,mode=0755 0 0
none /home/[username]/.cache/thumbnails tmpfs rw,noexec,nosuid,size=20%,uid=1000,gid=1000,mode=0755 0 0

That’s for security reasons. Less attack surface. It’s not for the purpose of saving disk space.

1 Like

I’m not concerned about saving space. I’m asking for the sake of the convenience of thumbnails. Would having thumbnails mounted to a tmpfs directory give less attack surface than having them normally, or does it make no difference?

No difference.

The code that parses the thumbnails (file manager) is already running. If it can be exploited by crafted images then it turns malicious. So noexec and tmpfs likely aren’t helpful.

1 Like

I will have to research this concept of malicious thumbnails further, I’ve never heard of that, but I believe it. What about letting an external program generate thumbnails? Like an image viewer with a browser view. Would that offer any degree of containerization, as they aren’t being generated by a program as deeply integrated into the DE as Thunar? Is this an ffmpeg problem? Maybe an image-viewer Flatpak that ships with it’s own build?

Then these create a thumbnails. There is nothing inherently wrong with thumbnail creation. Only if the application creating the thumbnail is malicious. Or a hypothetical vulnerability where the user downloads a specifically crafted image, which results in the created thumbnail to be malicious so it can exploit another application parsing thumbnails.

Added a rationale here just now, maybe that will help to explain better why that has been implemented: