I am (or was) running Ubuntu 14.04.05.

I've been noticing a lot of files titled simply = that appear above the . and .. when you inspect a directory with ls -al and another empty file called simply 0 in folders spread out across the file system, but primarily in my /home/user/ folder and it's subdirectories. I can remove 0 by inode with find . -inum $inode_of_equal_sign -exec rm {} \;. However I cannot delete the = file, using any technique I could find for getting rid of filenames with special characters, nor could I identify the process that keeps replacing them.

I can't stat a majority of files using lsof or stat or file or any other utilities as I keep getting an error can't stat /run/users/1000/gvfs if I unmount it, it gets remounted. It also appears to be owned by UID 999, which is the ubuntu live setup user. I looked through the devices folder, and there it seems that /dev/fuse is owned by root:pulseaudio, and refuses to stay deleted, or be unlocked.. This strikes me a somewhat suspect to understate it as dramatically as possible, as this is my development machine, and I have stripped it of all unnecessary packages and services, which includes all audio and printer packages, config files, and kernel modules. The pulseaudio group also owns a few files/folders in other parts of the system. I've traced it back to systemd which, as far as I can tell, only starts processes, which are already started by upstart. The config files in /etc/systemd are almost all symlinks back to /lib/systemd, I eliminated the systemd from upstart, restarted but it appears that systemd or whatever this actually is, is actually started by PID 2, D-Bus... Not exactly sure what to do about that, never manually configured anything in D-bus before. then noticed several .so files in /var/lib/systemd and /lib/systemd/ with names that seem like they were made with mktemp. A lot of them were binary, but the mimetype didn't match the shared object profile, a lot of them were symlinked to shared object files in the kernel library. There was also a folder /lib/xtables with a fistful of perl scripts for what I guess we can call "non-standard" network utilities, and some binaries that I didn't examine. A few of the these mystery files turned out be simple text files containing the PIDs of processes related to this ... I dunno, secret feature? Undocumented daemon? Loaded by systemd.

(I feel like it's pretty safe to say I'm not exactly the owner of this system anymore, like maybe I'm just borrowing it now) I identified that all of the suspect files were created at approximately the same time. 3:33 on April 19th. So I started digging through the files that had been created at that time. They all seemed off. Found one, I forget which one, but it had ? characters for it's inode, all of it's permission attributes, it's size, etc.. when you viewed it with ls -ial I've seen a fair amount of weird schiz in my directories, terminal going crazy from accidentally cating some binary file, graphics glitches, etc.. but that one was new one on me.

Anyways, I'm wondering if anyone has seen this before. It's a self-replenishing system of sockets, symlinks, and files that centers around locking /dev/fuse to /run/user/<Your UID>/gvfs, and appears to create a sort of mirror gvfs locked to the id of your user. It survives reinstalltion in the hard disk, and even stopped some attempts to dd if=/dev/urandom of=/dev/sda it from a live disk on top. I also noticed the 0 files on a USB drive I was short-sighted enough to connect to try to save my work (which I did.) It assigns group ownership to files to groups that are common, (i.e. pulseaudio, alsa, but which are not necessarily in /etc/groups. Reading through the source of the live disc I installed, it seems that there are some perl scripts that set hooks for boot/installation events in place to load different efi files than the ones in the boot folder. This could be part of the secureboot thing though. I'm not sure. I'm downloading several other copies of ubuntu, and some other distros to compare against this which I have saved, but don't have a free isolated machine to use as a quarantine or a "clean room".

Just wondering if anyone else using ubuntu has seen this behavior before, and if this thing has a name already. Or.. you know.. If this is a hidden feature of the OS.. How do I disable it.

[UPDATE:] I found this: https://unix.stackexchange.com/questions/77453/why-cannot-find-read-run-user-1000-gvfs-even-though-it-is-running-as-root#77592 which explains not being able to stat the objects of my attention as root. However, I still can't explain the = & 0 why /dev/fuse would be locked and owned by root:pulseaudio when there is no trace of pulseaudio on the system, including a listing for it in /etc/group.

  • I wonder what a fsck would have to say about this. – Jos May 3 '17 at 11:02
  • "Can't stat() <filename> /run/user/1000/gvfs denied. File or resource busy"... Something along those lines. Some of file system analysis tool, (I can't remember which one) said that it was an ext2 partition, when I definitely formatted it as ext4. – blanket_cat May 3 '17 at 11:06
  • 1
    An ext4 partition will show as ext2 in fsck -- they use the same filing scheme, the difference is journalling, which aids recovery after an unexpected shutdown (among other things). – Zeiss Ikon May 3 '17 at 11:07
  • Thanks for the tip. I plugged in the disk after loading a different live distro, and it's not stopping my dd if=/dev/urandom of=/dev/sda overwrite anymore. Just frustrated because I'm in a rather furiously paced dev cycle. – blanket_cat May 3 '17 at 11:14

I've never seen anything like this on any of my Linux systems (been dabbling for years, running Linux exclusively for five years and Ubuntu for three).

That said, this is very similar to the behavior of various Windows malware species. It's possible ClamAV could improve things if you can install it on a flash drive with an installed (as opposed to Live) Ubuntu on it, but the more reliable method would be to write a Live USB on another (clean) computer and boot from it, then reinstall your OS (and wipe your /home). Yes, this will lose all your stored information -- but as you note, you don't own this computer any more, and whoever is letting your borrow it can revoke that at any time, already has any information they want, and can take it from you without notice; effectively, it's already gone.

It might be worthwhile to try copying things like text documents, photos, etc. to another medium, then examining that medium from a Live media boot to check for these "off" files -- but I'd be surprise if whatever is living in your system didn't plant itself on your backup media, and if it does, it would not be safe to mount that medium on the system after cleaning it.

| improve this answer | |
  • Yeah, I booted under a DVD copy of mint, and tried torching the / /boot /tmp /var /var/tmp /var/log /var/log/audit and swap partitions.. then went to attempt to access the home folder through the ecryptfs-unlocker-...thingy whatever that program's called, but it wouldn't unlock with my password, and the installer never asked for an encryption passphrase because I did my own thing with the partitions. Exactly, it reminded me of stuff I got on Windows back in the days of Limewire. :) I'll give ClamAV a deeper look. – blanket_cat May 3 '17 at 11:19
  • I mean, that's not to understate the sophistication. I mean, from a developer/sys admin's perspective, it's pretty masterful, aside from how easy it is see. – blanket_cat May 3 '17 at 11:29
  • 1
    The easy visibility would go right over the head of a normal user -- even of Linux. Most folks have no idea what their filesystem is supposed to contain. Far from the days of 40 MB hard disks, when I could hex edit my FAT to halve my cluster size, gaining back a significant amount of cluster end waste space, even I don't really know how ext* works. Just hasn't been worth my time, as a user rather than hacker, to learn. – Zeiss Ikon May 3 '17 at 11:44
  • Haha! Yeah, I guess you're right. I'm just working on some tools for Linux, (just wrote my first man page, which was literally the most difficult programming challenge of the project) and have had to get deeper into the internals than I ever thought I would. And as far as the differences between the file systems, dealing with creating bootable USBs and working across different OS's, I haven't been able to find a concise, clear, explanation of the exact differences between, and pros and cons, for different file system architectures anywhere. – blanket_cat May 3 '17 at 11:54
  • Might try here: thegeekstuff.com. They come up on top in a search for how ext2 and ext2 differ, with an article that claims to explain all three ext* versions. – Zeiss Ikon May 3 '17 at 12:29

So I was running a script that mounted a file system, and chrooted into it to make changes then recompiled it into an ISO. I was trying to use some fancy ternary operator instead of an if statement because it would have made verbosity and log-level adjustment significantly trivial. (This project was my exercise/excuse to go through the ABSG, not for work.)

So what worked during my normal testing conditions, do to my neglect, did not when the variable would not meet the condition. Can't remember exactly how it worked but it was something like:

(( "$verbosity" >= "1" ))

and, since $verbosity must have been null during a case, and I was chrooting with proc, sys, dev, without a net like LXC(D|FS) or virtual box or docker of whatever, so it was writing "" to the file = in any directory I ran the script from.


Use virtualization for system resources when you chroot my friends.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.