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'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.
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:
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.FACE. PALM.
Use virtualization for system resources when you chroot my friends.