Excessive disk writes when '/etc' location is opened as root

[L-U-T-i]

Expected behaviour

Everything shall be exactly the same as when '/etc' folder is browsed as any other user, or any other location is browsed as root (no excessive disk writes).

Screenshot: '/etc' folder is browsed as a non-root user (see no particular disk activity):

Screenshot: '/etc' folder is browsed as a non-root user (see disk activity dropped as soon as moved from '/etc' to '/'):

Screenshot: '/etc' folder is browsed as a non-root user (see disk activity dropped as soon as moved from '/etc' to '/etc/cron.d'):

Actual behaviour

There is excessive disk write activity present when open (browse) '/etc' folder in caja as root user.

Screenshot: '/etc' folder is browsed as a root user (see disk activity increased significantly as soon as moved to '/etc'):

Steps to reproduce the behaviour

Launch caja as root, and browse to '/etc' folder. You can see excessive disk writes by caja in system monitor or using (for example):

Screenshot (while '/etc' is opened in another caja window): iotop -a -o -u root (see caja threads):

Screenshot (while '/etc' is opened in another caja window): iotop -a -P -o -u root (see caja process):

Screenshot (note the difference when '/etc' is opened in another caja window after 11:07:12): pidstat -dlt 10

MATE general version

1.26.0

Package version

caja-1.26.1-1.el9.x86_64

Linux Distribution

Rocky Linux 9.0

Link to bugreport of your Distribution (requirement)

Reporting here directly to EPEL packager Wolfgang Ulbrich fedora@raveit.de... ;-)

[lukefromdc]

I was just unable to duplicate this with sudo caja didn't get the warning messages either. Runing caja under su, I got the same warnings but no indication of high disk usage/writes. What extensions are you enabling in caja, that might make a difference?

[L-U-T-i]

I have installed caja, caja-core-extensions, caja-actions (together with dependency caja-actions-doc) and caja-schemas - all from EPEL-9 repo, as provided by raveit65. I am running Rocky Linux as virtual machine, but I don't think it matters.

What is interesting is I've noticed that some months ago (Rocky Linux 8, my own build of caja 1.26), but I didn't have time to report at that time (and, considering it is my build, it could be the reason, so I wanted to investigate a bit more before opening an issue, in particular as it happened on only one machine, while I've had 3 almost the same...). I've checked now (no changes since then on those machines), and it doesn't happen now on any of those 3 Rocky 8 machines. It is very strange...

Which part of caja (that makes a difference between a root user and non-root user) could initiate such writes with 4 threads? It may be /etc folder or something within it that triggers those writes...

[L-U-T-i]

About the messages - probably they are not relevant to this issue at all, but to caja running as su. I've put terminal window to screenshots so you can see exactly what is installed ('rpm -qa | grep caja' output) and how I've launched caja.

[lukefromdc]

Indeed I see those only running caja under su. I have not by any means been able to duplicate the disk writes, though I've only ever worked on bare hardware

[L-U-T-i]

in this case, I haven't start session as root (even if I exceptionally do that when really necessary as well, but probably no need to go through that again, considering we've had this discussion in the past already ... ;-)). If I'd been logged in as root, there wouldn't be "(as superuser)" in the title of caja window, or?

About this issue: In terminal, I've su (from normal user being logged in as to root) and launched caja from there after, as I needed to browse some folders as root. I sure have reasons to do that from time to time, and it is probably not only me ;-) How else to browse /var/log folders or /etc or any other system folders?

I appreciate your work as MATE maintainer, as well as Fedora / EPEL packager. You have all rights to support (or to not support) some acts other people do. But, as long as this doesn't put you in danger, or doesn't put in danger someone else with something you provide, I really don't see why it should be of your concern. If I feel I need to kick my head with a stone, why bother about? It is about my head only at the end... ;-)

I do run MATE as a normal user generally, of course. I'm not stupid... :-)

And yes, I'm aware most probably I will have to fix it by myself...

PS: I've called your name just to fill the "Link to bugreport of your Distribution (requirement)" section, because I don't think it would make sense to fill Bugzilla with that (the package doesn't come from RHEL / Rocky Linux at the end), and I jus't don't know how to report bugs to EPEL. On the other hand, if I would leave it empty, I'd disk you would attach me a "Template not respected" (or whatever the red tag is...) ;-)

[lukefromdc]

Actually, fixing things myself is how I ended up working on MATE and maybe how a lot of FOSS programmers begin.

One reason for warnings about not starting entire graphical sessions as root (except in emergency system recovery cases) is the danger posed if a user forgets they are running as root and starts a browser. I think Firefox now has code to refuse to run as root but no idea if Chrome et all also do. A browser in a root session takes you right back to the Windows 95/98 security situation where any malicious website can get at the entire system

[L-U-T-i]

Again, I haven't been logged in as root, just opened caja window as root!!! Why so much talk about some general security rules and good practices (again), but nothing about the issue...?

I have written exactly what happened, as much as I knew. Besides, I've provided output of 'iotop' and 'pidstat' commands - as screenshots (to proove what system monitor indicated). If you look at the screenshots, you can see that the first one is a non-root caja window in /etc - and, it is also written above it. After, there are 3 screenshots with caja ran as a root user, where you can see in system monitor that there is excessive disk activity only if in '/etc' (not in '/' and not below '/etc', as /etc/cron.d). How can I present the issue more precisely? Or, with less screenshots.

If you would read my first post a bit more carefully, I think there should be no misunderstanding. If you see just a red flag as soon as you see something related to a root user, it can easily happen that you miss other "details"... ;-)

Don't tell me you do just everything in shell (like list all of the files in some system folder, and do all actions there just through bash commands...)? If for instance you want to check the sizes of log files, clean out some of those, compare old versions of some configuration files etc. ;-) I have to admit I like MATE just because I can browse the system files as root, and do some actions in a more comfortable way. This doesn't mean I need to be logged in as root though. If you hate root so much, why is there "open as adminirtrator" caja action avalable? ;-)

In any case, back to my issue. The output of: sysdig | grep caja | grep /etc gives me (this is just a small cut-out, lines come out like crazy...): 4022329 21:18:40.276431948 0 gdk-pixbuf-thum (196419) < execve res=0 exe=/usr/bin/gdk-pixbuf-thumbnailer args=-s.128.file:///etc/favicon.png./tmp/.mate_desktop_thumbnail.LLORS1. tid=196419(gdk-pixbuf-thum) pid=196419(gdk-pixbuf-thum) ptid=174937(pool-caja) cwd= fdlimit=1024 pgft_maj=0 pgft_min=46 vm_size=400 vm_rss=4 vm_swap=0 comm=gdk-pixbuf-thum cgroups=cpuset=/.cpu=/.cpuacct=/.io=/.memory=/user.slice/user-1000.slice/session-2.sc... env=SHELL=/bin/bash.SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/1718,unix/unix:/tm... tty=34821 pgid=81724(caja) loginuid=1000 flags=1(EXE_WRITABLE) 4024810 21:18:40.279476317 0 gdk-pixbuf-thum (196419) < clone3 res=196420(gdk-pixbuf-thum) exe=/usr/bin/gdk-pixbuf-thumbnailer args=-s.128.file:///etc/favicon.png./tmp/.mate_desktop_thumbnail.LLORS1. tid=196419(gdk-pixbuf-thum) pid=196419(gdk-pixbuf-thum) ptid=174937(pool-caja) cwd= fdlimit=1024 pgft_maj=0 pgft_min=317 vm_size=236992 vm_rss=6392 vm_swap=0 comm=gdk-pixbuf-thum cgroups=cpuset=/.cpu=/.cpuacct=/.io=/.memory=/user.slice/user-1000.slice/session-2.sc... flags=41990659(CLONE_FILES|CLONE_FS|CLONE_PARENT_SETTID|CLONE_SIGHAND|CLONE_SYSVSEM|CLONE_THREAD|CLONE_VM|CLONE_CHILD_CLEARTID|CLONE_SETTLS) uid=0 gid=0 vtid=196419(gdk-pixbuf-thum) vpid=196419(gdk-pixbuf-thum) 4024857 21:18:40.279515133 2 gdk-pixbuf-thum (196420) < clone3 res=0 exe=/usr/bin/gdk-pixbuf-thumbnailer args=-s.128.file:///etc/favicon.png./tmp/.mate_desktop_thumbnail.LLORS1. tid=196420(gdk-pixbuf-thum) pid=196419(gdk-pixbuf-thum) ptid=174937(pool-caja) cwd= fdlimit=1024 pgft_maj=0 pgft_min=0 vm_size=236992 vm_rss=6392 vm_swap=0 comm=gdk-pixbuf-thum cgroups=cpuset=/.cpu=/.cpuacct=/.io=/.memory=/user.slice/user-1000.slice/session-2.sc... flags=0 uid=0 gid=0 vtid=196420(gdk-pixbuf-thum) vpid=196419(gdk-pixbuf-thum) 4029936 21:18:40.287547396 2 pool-caja (174937) < write res=4096 data=.PNG........IHDR..............>a.....sBIT....|.d...."tEXtThumb::URI.file:///etc/ 4031078 21:18:40.289614467 2 pool-caja (174937) < read res=8192 data=.PNG........IHDR.............\r.f....sBIT....|.d...."tEXtThumb::URI.file:///etc/ 4089436 21:18:40.393907611 0 gdk-pixbuf-thum (196421) < execve res=0 exe=/usr/bin/gdk-pixbuf-thumbnailer args=-s.128.file:///etc/favicon.png./tmp/.mate_desktop_thumbnail.13NSS1. tid=196421(gdk-pixbuf-thum) pid=196421(gdk-pixbuf-thum) ptid=174937(pool-caja) cwd= fdlimit=1024 pgft_maj=0 pgft_min=46 vm_size=400 vm_rss=4 vm_swap=0 comm=gdk-pixbuf-thum cgroups=cpuset=/.cpu=/.cpuacct=/.io=/.memory=/user.slice/user-1000.slice/session-2.sc... env=SHELL=/bin/bash.SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/1718,unix/unix:/tm... tty=34821 pgid=81724(caja) loginuid=1000 flags=1(EXE_WRITABLE) 4091850 21:18:40.396885025 0 gdk-pixbuf-thum (196421) < clone3 res=196422(gdk-pixbuf-thum) exe=/usr/bin/gdk-pixbuf-thumbnailer args=-s.128.file:///etc/favicon.png./tmp/.mate_desktop_thumbnail.13NSS1. tid=196421(gdk-pixbuf-thum) pid=196421(gdk-pixbuf-thum) ptid=174937(pool-caja) cwd= fdlimit=1024 pgft_maj=0 pgft_min=319 vm_size=236992 vm_rss=6524 vm_swap=0 comm=gdk-pixbuf-thum cgroups=cpuset=/.cpu=/.cpuacct=/.io=/.memory=/user.slice/user-1000.slice/session-2.sc... flags=41990659(CLONE_FILES|CLONE_FS|CLONE_PARENT_SETTID|CLONE_SIGHAND|CLONE_SYSVSEM|CLONE_THREAD|CLONE_VM|CLONE_CHILD_CLEARTID|CLONE_SETTLS) uid=0 gid=0 vtid=196421(gdk-pixbuf-thum) vpid=196421(gdk-pixbuf-thum) 4091868 21:18:40.396899372 2 gdk-pixbuf-thum (196422) < clone3 res=0 exe=/usr/bin/gdk-pixbuf-thumbnailer args=-s.128.file:///etc/favicon.png./tmp/.mate_desktop_thumbnail.13NSS1. tid=196422(gdk-pixbuf-thum) pid=196421(gdk-pixbuf-thum) ptid=174937(pool-caja) cwd= fdlimit=1024 pgft_maj=0 pgft_min=0 vm_size=236992 vm_rss=6524 vm_swap=0 comm=gdk-pixbuf-thum cgroups=cpuset=/.cpu=/.cpuacct=/.io=/.memory=/user.slice/user-1000.slice/session-2.sc... flags=0 uid=0 gid=0 vtid=196422(gdk-pixbuf-thum) vpid=196421(gdk-pixbuf-thum) 4096846 21:18:40.404956278 2 pool-caja (174937) < write res=4096 data=.PNG........IHDR..............>a.....sBIT....|.d...."tEXtThumb::URI.file:///etc/ 4097894 21:18:40.406804059 2 pool-caja (174937) < read res=8192 data=.PNG........IHDR.............\r.f....sBIT....|.d...."tEXtThumb::URI.file:///etc/ 4131449 21:18:40.513737033 2 gdk-pixbuf-thum (196424) < clone3 res=0 exe=/usr/bin/gdk-pixbuf-thumbnailer args=-s.128.file:///etc/favicon.png./tmp/.mate_desktop_thumbnail.55OVS1. tid=196424(gdk-pixbuf-thum) pid=196423(pool-caja) ptid=174937(pool-caja) cwd= fdlimit=1024 pgft_maj=0 pgft_min=0 vm_size=236992 vm_rss=6320 vm_swap=0 comm=gdk-pixbuf-thum cgroups=cpuset=/.cpu=/.cpuacct=/.io=/.memory=/user.slice/user-1000.slice/session-2.sc... flags=0 uid=0 gid=0 vtid=196424(gdk-pixbuf-thum) vpid=196423(pool-caja) 4135179 21:18:40.522012317 2 pool-caja (174937) < write res=4096 data=.PNG........IHDR..............>a.....sBIT....|.d...."tEXtThumb::URI.file:///etc/ 4136240 21:18:40.524051328 2 pool-caja (174937) < read res=8192 data=.PNG........IHDR.............\r.f....sBIT....|.d...."tEXtThumb::URI.file:///etc/ 4185573 21:18:40.628843101 3 gdk-pixbuf-thum (196425) < execve res=0 exe=/usr/bin/gdk-pixbuf-thumbnailer args=-s.128.file:///etc/favicon.png./tmp/.mate_desktop_thumbnail.TGTMS1. tid=196425(gdk-pixbuf-thum) pid=196425(gdk-pixbuf-thum) ptid=174937(pool-caja) cwd= fdlimit=1024 pgft_maj=0 pgft_min=46 vm_size=400 vm_rss=4 vm_swap=0 comm=gdk-pixbuf-thum cgroups=cpuset=/.cpu=/.cpuacct=/.io=/.memory=/user.slice/user-1000.slice/session-2.sc... env=SHELL=/bin/bash.SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/1718,unix/unix:/tm... tty=34821 pgid=81724(caja) loginuid=1000 flags=1(EXE_WRITABLE) 4187446 21:18:40.631826003 3 gdk-pixbuf-thum (196425) < clone3 res=196426(gdk-pixbuf-thum) exe=/usr/bin/gdk-pixbuf-thumbnailer args=-s.128.file:///etc/favicon.png./tmp/.mate_desktop_thumbnail.TGTMS1. tid=196425(gdk-pixbuf-thum) pid=196425(gdk-pixbuf-thum) ptid=174937(pool-caja) cwd= fdlimit=1024 pgft_maj=0 pgft_min=320 vm_size=236992 vm_rss=6480 vm_swap=0 comm=gdk-pixbuf-thum cgroups=cpuset=/.cpu=/.cpuacct=/.io=/.memory=/user.slice/user-1000.slice/session-2.sc... flags=41990659(CLONE_FILES|CLONE_FS|CLONE_PARENT_SETTID|CLONE_SIGHAND|CLONE_SYSVSEM|CLONE_THREAD|CLONE_VM|CLONE_CHILD_CLEARTID|CLONE_SETTLS) uid=0 gid=0 vtid=196425(gdk-pixbuf-thum) vpid=196425(gdk-pixbuf-thum) 4187478 21:18:40.631868386 2 gdk-pixbuf-thum (196426) < clone3 res=0 exe=/usr/bin/gdk-pixbuf-thumbnailer args=-s.128.file:///etc/favicon.png./tmp/.mate_desktop_thumbnail.TGTMS1. tid=196426(gdk-pixbuf-thum) pid=196425(gdk-pixbuf-thum) ptid=174937(pool-caja) cwd= fdlimit=1024 pgft_maj=0 pgft_min=0 vm_size=236992 vm_rss=6480 vm_swap=0 comm=gdk-pixbuf-thum cgroups=cpuset=/.cpu=/.cpuacct=/.io=/.memory=/user.slice/user-1000.slice/session-2.sc... flags=0 uid=0 gid=0 vtid=196426(gdk-pixbuf-thum) vpid=196425(gdk-pixbuf-thum) 4191757 21:18:40.640240380 2 pool-caja (174937) < write res=4096 data=.PNG........IHDR..............>a.....sBIT....|.d...."tEXtThumb::URI.file:///etc/ 4192000 21:18:40.640726425 3 pool-caja (174936) < access res=0 name=/etc 4192071 21:18:40.640863392 3 pool-caja (174936) < access res=0 name=/etc/favicon.png 4192075 21:18:40.640867086 3 pool-caja (174936) < access res=0 name=/etc/favicon.png 4192077 21:18:40.640869810 3 pool-caja (174936) < access res=-13(EACCES) name=/etc/favicon.png

As you can see, /usr/bin/gdk-pixbuf-thumbnailer iskeeping on do something with /etc/favicon.png./tmp/.mate_desktop_thumbnail.xxxxxx (where xxxxxx keeps changing all the time with avery short period).

Does this info help to get an idea about where the issue could coming from?

[L-U-T-i]

I read extremely carefully your previous again, but I still can see only:

Nothing about

Sorry I couldn't understand what you've ment... ;-)

[L-U-T-i]

And,

Again, I haven't been logged in as root, just opened caja window as root!!!

was not a reply to just you (and, in particular not to what you've related it to...), but more generally (as also @lukefromdc explained me why it is not a good idea to run sessions as root...).

Therfore, I've indicated the part which should be more a reply to you with your name after this paragraph...

[L-U-T-i]

Sorry for all misunderstandings again.

[lukefromdc]

This looks like for some reason, when you open /etc as root, caja is trying to thumbnail a bunch of files, Text thumbnailing does not work with current versions of GTK3, but I could potentially see that still causing disk writes if support for it broken and not entirely removed from GTK3 (no idea which on my part). Lots of text files in /etc Other than that, any symlink to a directory full of anything that can be thumbnailed or any other interaction with such a directory could do it.

Remember that ALL of your home directory thumbnails were made when normally logged in. I just tested caja both with sudo and su, it looks like sudo caja uses existing thumbnaiils, with caja under su writes new ones in /root/.cache/thumbnails/normal

[lukefromdc]

"Open as adminstrator" by the way is an extension, not caja itself. This can be done with the old GKSU extension on systems still using GKSU, or with third party extensions like the python caja-admin extension, which is what it sounds like you have installed and which I have on my own system. That might have been a distro decision.I mostly use it to ensure python support for extensions is working as I normally open root file browser windows from terminal (and yes, for local filesystems only and never over a network).

Opening a root instance of caja and then using it with an over the internet extension (say caja-dropbox or google drive support) would expose you to any attack possible from an attack on those sites, a man in the middle attack, a weakness in GVFS(from which remote filesystems are accessed), or one in the extension or in Caja itself.

[L-U-T-i]

@lukefromdc, thank you for a very useful information.

I've renamed existing '/root/.cache/thumbnails' folder, and after the new one has been generated, the issue seem to be resolved for the moment. I can browse '/etc' as a root user now without any issues.

Probably it would still be good to investigate what happened and why, because I'm afraid this issue can (and, probably will, sooner or later) pop out again.

If it helps, the old (troublemaking) '/root/.cache/thumbnails' contains '/root/.cache/thumbnails/fail/mate-thumbnail-factory/129812107bd8a9253d27eccd329f5ad3.png' (filename probably doesn't matter, but obviously something went wrong while mate-thumbnail-factory has been doing something...). All permissions seem to be normal, as well as selinux context (set to permissive for now, anyway). The file is a 235 bytes 1x1 px image, within I've managed to find: EXtThumb::URI\00file:///home/luti/TEMP/system-root/usr/bin/fix-qdf\E0a\8A\00\00\00t 'home/luti/TEMP/system-root/usr/bin' folder is most probably a copy from the old Rocky Linux 8.6 setup (I am building a new Rocky Linux 9 now...). What I find interesting is that even if I open the same location ('/home/luti/TEMP/system-root/usr/bin') as a root user now, exactly the same '/root/.cache/thumbnails' contains '/root/.cache/thumbnails/fail/mate-thumbnail-factory/129812107bd8a9253d27eccd329f5ad3.png' file (diff shows no difference) reappears, but I can still browse '/etc' as root this time, without an issue.

Could it be that some other thumbnail (in '/root/.cache/thumbnails/normal' or in '/root/.cache/thumbnails/large') can cause this strange behavior?

According to an output of sysdig (in my previous post), '/etc/favicon.png' seem suspicious to me, but it is still there (the whole '/etc' is exactly the same as before, in fact).

I don't use caja-dropbox or google drive (exactly for security reasons). If I had to do something over the network, it is just my safe LAN, or through OpenVPN from another secure LAN. So I don't think I'm exposed too much... ;-)

[lukefromdc]

I don't really know what's working differently after regenerating the thumbnails folder, but this sounds like corrupted files may have been an issue.

[L-U-T-i]

Shouldn't a corrupted file just be overwritten in such a case? As said, permissions haven't been a problem (all thumbnail files R/W by root, 0600), so already the first write attempt should be successful, or?

[lukefromdc]

I really don,'t know what's going on wirh that, something may have been putting the thumbnailer into a loop such as failed writes but really no idea given I cannot duplicate it.

[L-U-T-i]

Can you indicate where in the code ismate thumbnailer, please. Maybe I can try to look into where the writes happen, and somehow try to prevent such a loop (in case of unsuccessful write...), the next time I manage to reproduce the issue (at the moment, everything seems to work just fine).

[L-U-T-i]

I think I've found it - is 'mate-desktop/libmate-desktop/mate-desktop-thumbnail.c' the right place?

I've also found an interesting info in cinnamon commits, stating that:

There are various different behavior depending on whether the application ran with sudo, pkexec, under the root user, and 'sudo su'...

• sudo (program) keeps the user's home folder (and their .cache folder)
• pkexec (program) uses root's .cache folder
• root terminal, running (program) uses root's .cache folder
• sudo su, then running (program), uses root's .cache folder

Using sudo, or sudo su, SUDO_UID and friends are set in the environment Using pkexec, PKEXEC_UID is set

root terminal and pkexec cases don't need any extra work - they're thumbnailing with the correct permissions (root-owned in root's .cache folder)

sudo and sudo su need help, and each in a different way:

• sudo su gives a false positive, since SUDO_UID is set, but the program is using root's .cache folder, so we really don't want to fix these
• sudo (program) wants to use the user's cache folder, but will end up writing them as root:root files, instead of user:user. So, in this case, we make sure to chmod those files to be owned by the original user, and not root

There are 2 interesting extra lines in cinnamon desktop gnome_desktop_thumbnail_factory_init function, comparing to mate_desktop_thumbnail_factory_init function:

get_user_info (factory, &priv->needs_chown, &priv->real_uid, &priv->real_gid);

priv->permissions_problem = !gnome_desktop_thumbnail_cache_check_permissions (NULL, TRUE);

@lukefromdc, do you think my issue can somehow be related to that? Or, do we check about permissions in MATE somewhere else (so those checks would actually be unneeded)?

If my issue can be related to that, I can try to merge some cinnamon commits like:

• af0f6ee
• e194389
• 59f0108
• fce4621
• afb166b

to my build, if I manage to reproduce the issue, and see if it resolves it.

[lukefromdc]

That should be the right file. The problem you describe certaily sounds like a possible cause, though I would expect it to be consistant if so. I don't know a whole lot about the details of this part of the code. What we DO need to avoid is creating any files owned by root in the user's home directory. A variety of things in Caja can do that (and all of them are inconsistant in my experience) when running as root. All of them create later problems next time the normal user tries to do anything requiring interacting with the offending files. The only time this should ever be allowed to happen is intentional creation of (usually non-hidden) files by the user running as root, something I do for instance in packing custom .deb packages

If you can apply or backport those commits, do so and I can test them for any new problems (given that I cannot duplicate your original problem) and call for a 2nd review which will be needed for a relatively complex PR like this from outside the core team.

Still odd behavior: can you duplicate it with the fresh thumbnails directory? I suppose this mixture could have written files with wrong permissions somewhere, thus causing the thumbnailer to loop and keep attempting to write. It should error out in this sort of case, not get stuck in a loop.

[L-U-T-i]

I've already renamed the problematic thumbnails directory, as described above. I have no issue since then, and can also not duplicate it anymore. I have deleted the old (problematic) thumbnails directory in between (by mistake - I've created many copies of a thumbnail directory, and wanted to get rid of those copies after...), unfortunately, so I can not reproduce the situation at the moment.

What is important is that we are talking about the thumbnail cache directory in '/root', so even if some file would have the wrong permissions (but I've checked all permissions in a problematic thumbnail directory and they were all root:root 0600), this should not be a problem (to overwrite as root).

What could potentially be a problem is if something would try to rewrite some thumbnail (in '/root', already there with root:root permissions) witht a logged in (non-root) user permissions.

The thumbnail directory of a currently logged in (non-root) user is not problematic, since it is still exactly the same as before, and no issue. Besides, the browsing of any location as this user haven't caused the issue. I therfore believe we have to focus on what was going on while working with thumbnails in '/root' thumbnail cache only.

I have made a patch to apply the commits as above: mate-desktop-1.26.0-thumbnailer.patch.txt and successfully built a test release with it.

I've found another interesting commit there, which checks if a thumbnailer binary actually exist. A part of this commit is here attached: mate-desktop-1.26.0-thumbnailer-bin.patch.txt and built another test release with this patch (without the one above; it should be adapted if applied on top of the other one...).

I have those test builds ready if I anyhow manage to reproduce the issue.