What are these files "tmp-mount-*," and "zeb_def_ipc_*." in "/tmp" directory? Which process is creating these files?

Do you use Zoom? If so, it is the likely culprit of some of the zeb_def_ipc... setuid files in /tmp. Quit Zoom.

To set up file system monitoring, use fs_usage and filter the results. For example, if you want to see when the zeb_def_ipc... files are created and by what process, run this command in Terminal:

sudo fs_usage -f filesys | grep /tmp/zeb 

With fs_usage monitoring the file system, Open Zoom. You will see an event like:

10:03:41  unlink            private/tmp/zeb_def_ipc_16506                                                    0.000011   zoom.us     

Quit Zoom. Open it again. You should get another report. If you don't use Zoom, run the command above and launch all your tools and watch the right column to see which process is spawning the files.

Regarding the tmp-mount, I believe this can be the result of MDM policies that deliver DMG payloads. Have you mounted a DMG, specifically via an MDM? Jamf will create the tmp-mount folders on systems when we deploy software via DMG.

Hope this is helpful.

naturetech wrote:

And why would I install malware on my system?.

More than a little modern malware comes with a EULA, these days.

More than a little of the rest with bugs, too.

And add-on security apps, add-on firewalls, and add-on VPN apps can be somewhere between problematic and sketchy.

I had never seen these kind of files in the "tmp" directory, so wondering what these files.

How many other Macs have you checked? (Preferably, sharing some common apps.)

/tmp is somewhere between transient storage and a self-cleaning garbage dump, and is available for all apps.

What is temporarily stored there depends entirely on what apps installed, including what version of those apps, and how well it’s all (not) playing together.

Various apps and services with Zebronics and Zeb-related strings domexist, seemingly including a vendor of network-connected cameras and speakers.

If looking at the locally-installed apps and gear, and at the file contents and running tools (such as the strings command), looking for substring matches doesn’t find a culprit, and if web searches fail, then perform a clean install, incrementally add the same catalog of apps, and then see which app was the most recent installed when the files appeared. If the directories are seemingly single-use, check the names in the hierarchy as well, and maybe set some file notifications that trigger when a file gets added or removed.

Identifying specific transient files? It’s a slog. And probably fruitless, unless somebody happens to share some of the same configuration you do, or happens to otherwise recognize the particular transient files getting dropped off by some particular app. Or the file names chosen are sufficiently unique that web searches can reveal the culprit app. These aren’t.

naturetech wrote:

Hi Apple Team,

I recently began noticing some unusual files in the "/tmp" directory, including "boost_interprocess," "tmp-mount-*," and "zeb_def_ipc_*." I have never encountered these types of files before. I attempted to identify which process created them but was unsuccessful. I also ran a malware scan with Malwarebytes, and it reported no issues.

Could you please advise me on how to determine which process is creating these files and the reason behind them?

Thank you!

I just looked in my /tmp folder (not sure I ever remember looking there before) and I must say, there isn't much there, presumably because it is a temporary storage place and well written programs seem to clean up after themselves. There are three folders and one file, with names like "xxxAdobexxx," "com.apple.xxx.xxx," "MozillaUpdatexxxxxx," and "xxxlog" fairly easy to identify where they came from, either from the names or from Get Info. And they all have zero bytes storage shown although the entire folder seems to be using 8 KB. And all are less than 24 hours old.

So while I initially thought Etresoft and the other repliers were maybe being a little harsh on you, maybe now I'm not so sure.

How about you download Etrecheck and post its results here:

How to use the Add Text Feature When Post… - Apple Community

Etrecheck can identify some malware (which is usually unintentionally installed) or other things installed that might have led to your mystery files in tmp.

etresoft wrote:

naturetech wrote:

I’m pretty careful about the software I install and avoid any unofficial tools. Most of the tools I need come from Homebrew

That's one of the quickest segues into self-contradiction that I've ever seen. 😄

When I’m testing my proof-of-concept (PoC) projects, I usually work in the /tmp directory.

That's seems pretty risky as /tmp gets automatically cleaned out on a regular basis. I use my "Downloads" folder for this.

I'm just trying to be sure they aren’t malware.

My previous comments about malware were intended strictly for end users, not developers. Developers are much more likely to inadvertently install malware because they download lots of open-source, publicly available scripts and code from the internet, most of which comes from very large repositories with anonymous authorship and a history of security problems.

Developers are a great big target too, including malware and dreck installed via what gets downloaded. Xcode itself has been targeted on various occasions. For example, XCSSET has been around for ~five years, including earlier this year and that and other ilk is probably ongoing. There was a fake Homebrew site being advertised recently, too.

/tmp is definitely not where I’d store even temporary projects. I use ~/tmp for this stuff. /tmp tends to vaporize on a whim. And if I miss or mistype ~/tmp, oh well, /tmp got “whimmed” early. 🤷‍♀️

naturetech wrote:

…As a developer, …

As a developer, you are undoubtedly accustomed to incorporating messages and techniques unique to your code and to your preferred style of working, and familiar with shared projects with diagnostic and logging and analytics tooling specific to that project. These can be quite unique, and in specific cases these details have even been used to (forensically) uniquely identify groups of developers and even specific developers.

You are here seeking to “scratch your itch”, and seeking to know things local to your own and very specific mix of apps and services. This as pretty much every (non-managed, non-supervised) device is unique within weeks and often within hours of its first install. Your particular itch here is slightly unusual too, as most folks seeking to scratch similar itches are looking at analytics and telemetry first, and less commonly at the /tmp contents. 😉

As a developer, you are familiar with the general steps useful for debugging and troubleshooting. Here, this research can mean wiping this configuration, and watching what happens with each added app and service, and each activated service. Yeah, this is a hassle, but some of these messages are unique to some particular app or service, and, well, nobody runs everything. Also potentially with using a second or third device, looking for commonality across most or all, a commonality which would usually point to Apple activities. This in addition to web searches for existing discussions, and sometimes searches for existing source code, whether the open-source parts of macOS or for messages unique to other chatty open-source projects.

For this case? com.apple.MobileSoftwareUpdate is a reversed-URL identifier used by legitimate Apple update-related apps. (As with everything potentially targeted, whether there are other and “creative” users “borrowing” this identifier? Here, probably not.)

Having used a few keywords and DDG finds some existing discussions of this particular identifier, including:

https://apple.stackexchange.com/questions/421738/what-is-com-apple-mobilesoftwareupdate-updatebrainservice-doing

Given your interest in OS internals, I’d also suggest acquiring the three volumes of Jonathan Levin’s *OS Internals book; sometimes called the New OS X Internals book set. That’ll provide some background for understanding how the pieces fit together, as well as a foundation in the jargon used by Apple developers; the tools and techniques and terms often used by Apple’s own operating system and app development projects.

naturetech wrote:

Could you please advise me on how to determine which process is creating these files

Not possible.

and the reason behind them?

I'm sure it's for a good reason.

This is not how malware works. If you've installed malware, on purpose, to run some illegal, pirate version of expensive software, or watch some paid video stream or sporting event for free, then the problem is the malware, not the files that it might be writing. But if you haven't installed malware, then you don't need to worry.

To be clear about this, you must have installed the malware, on purpose, and purposefully bypassed multiple levels of Appel security protection to make that happen.

The rather ironic statement, included in @etresoft's good guidance above, suggesting that "you must have installed the malware" should, I believe, be interpreted as meaning that it takes a conscious decision on the part of the user to install any software on the Mac.

Installation of malware is rarely by choice, but inadvertent or unknowing installation does happen if one lets one's guard down.

If you look through the hundreds of thousands of files on the Mac, then you will find innumerable files of all types. Some you will recognize and most (?) you won't. If you go looking for "trouble", you'll probably find it. 😉

naturetech wrote:

I’m pretty careful about the software I install and avoid any unofficial tools. Most of the tools I need come from Homebrew

That's one of the quickest segues into self-contradiction that I've ever seen. 😄

When I’m testing my proof-of-concept (PoC) projects, I usually work in the /tmp directory.

That's seems pretty risky as /tmp gets automatically cleaned out on a regular basis. I use my "Downloads" folder for this.

I'm just trying to be sure they aren’t malware.

My previous comments about malware were intended strictly for end users, not developers. Developers are much more likely to inadvertently install malware because they download lots of open-source, publicly available scripts and code from the internet, most of which comes from very large repositories with anonymous authorship and a history of security problems.