Sometimes we have to use Matlab at work. Whenever that’s required, it brings pain for various reasons. My team managed to solve one of them for ourselves and other coworkers. Let’s start by describing where the issue comes from.

Mathworks, the company behind Matlab, provides a decentralized on-prem licensing services to track and authorize use of their products. Surprise, surprise, it’s called Network License Manger. The only validation it performs is through the shared licensing key and a username taken from the OS running Matlab. While the corpo-managed Windows don’t allow employees to change their usernames, Linux users can use whatever username they want. Here’s the issue: people who decided to use a custom, not-company-assigned username on their computers couldn’t use Matlab.

There were couple options to trick Matlab to start. Starting from the trivial “just use the blessed username”, through suing into another user just to execute Matlab, modifying network traffic on the fly, and ending on creating a wrapper that faked the username. We aimed for the last one.

After some straceing it turned out that Matlab first fetches the uid of the user that started it and later performs a lookup in /etc/passwd to get the username. emdej suggested that we use bubblewrap to fake the username associated with current user. The wrapping script looked more or less like this:

1. fetch current uid
2. take the blessed-corpo-username from an env variable or a config file
3. use the two from above to create a copy of /etc/passwd with an altered entry
4. exec bwrap with a bind for a real /etc/passwd and rest of the filesystem as-is.

The lesson learned from this story is that the Network License Manager’s authentication sucks (or at least it is configured poorly at our company). Theoretically we could fake all usernames to a single one as well as the reported hostnames (the combo was used to deduplicate licenses taken from the pool – one user could spin as many instances of matlab on one host as they wanted¹).