I got the email at 11 PM on a Tuesday.

Subject line: "Legacy Facility - Audit Required - Urgent"

No context. No pleasantries. Just an address forty minutes outside the city and a terse note: "Previous administrator left no documentation. Keys at front desk. Access codes attached. Complete audit by Friday."

The address led me here—to a data center that time forgot. The kind of place that gets built in the late 90s when everyone's terrified about Y2K and decides they need off-site redundancy. Then Y2K doesn't happen, the redundancy becomes the primary, and twenty years later nobody quite remembers what's running here or why it can't be shut down.

The security guard at the front desk looked relieved to see me. "You the computer guy? Thank god. Nobody's been here in months. Equipment keeps running though. Fans, lights, the whole thing. Power bill's insane."

He handed me a key ring that probably weighed two pounds and a sticky note with four different access codes. "Good luck in there. Place gives me the creeps after dark."

I should have paid attention to that.

The facility was a time capsule. Rack after rack of beige and black servers, some with branding from companies that went bankrupt in 2008. Cable management that suggested someone once cared, now sagging under the weight of accumulated dust and abandonment. The air conditioning still worked—the hum was hypnotic, almost alive.

I found the admin workstation in what must have been an office once. Someone's coffee cup still sat on the desk, lipstick stain visible on the rim. A calendar on the wall showed October 2019. Whoever worked here last had left in a hurry, or just... never come back.

The workstation was still on. Login screen glowing in the darkness.

I used the access codes from the sticky note. The system let me in without complaint. No forced password change. No security warnings about the last login being five years ago. Just... in.

Welcome to LEGACY-ADM-01
Last login: Mon Sep 15 03:47:23 2019 from 10.0.1.47

That timestamp bothered me immediately. 3:47 AM. Five years ago to the day, almost to the hour. What kind of admin is working at 3:47 in the morning? And from an internal IP, so they were here, in this building, at that hour.

I filed it away. Probably nothing.

Before I dive into what I found, let me teach you something fundamental. Something that separates Unix-like systems from the anarchic free-for-alls of early personal computers.

See, back in the early 1970s at Bell Labs, Ken Thompson and Dennis Ritchie had a problem. They were building Unix on a PDP-7—a machine with less computing power than your smart watch—and multiple users needed to share it. Computers cost more than houses back then. Sharing wasn't optional.

The question became: How do you keep users from stepping on each other's digital toes?

Their solution was elegant and brutal in its simplicity. Every file has an owner. Every process runs as a user. And there are rules—clear, unambiguous rules—about who can do what.

When you try to access any file in Linux, the system asks three questions in this exact order:

That's it. Three questions. The answers determine whether you get access or get denied.

It's the foundation of every security boundary in Linux. And it's about to become very relevant to what I found in this forgotten facility.

Let me start with the basics, because this is where things started feeling wrong.

Every process in Linux runs as a specific user. When you log in, your shell runs as your user account. When you launch a program, it typically runs as you. When you sudo something, it temporarily runs as root—user ID 0, the god account that can do anything.

Users are identified by three things:

Groups are just collections of users. They exist so you don't have to individually grant permissions to every developer on your team—you just make a developers group and manage it once.

Simple enough, right?

So I did what any sane admin does on an unfamiliar system. I checked who I was:

Command breakdown:

The output:

Okay. That's the account they gave me. Expected.

Then I ran:

Command breakdown:

The output:

Let me parse that for you:

And that's where my coffee went cold.

I was in groups called legacy_ops and facility_admin. Groups I'd never requested. Groups that weren't mentioned in any of the access documentation. I checked my onboarding email again—nothing about these groups.

Someone, or something, had added me to them.

When?

I checked the group files:

Command breakdown:

Output:

Three users in this group. Me, someone named dmorrow, and someone named mzaleski.

I didn't know those names. Time to check who they were:

Command breakdown:

Output:

Real accounts. With home directories. With login shells.

I checked the last login records:

Command breakdown:

Output:

September 15, 2019. The same day as the last login to this workstation.

Mzaleski had logged in at 3:47 AM. That timestamp again.

I stared at that output for a long time in the dim server room. The only sound was the mechanical breathing of the air conditioning and the occasional click-whir of a hard drive seeking.

These people hadn't logged in for five years. But I was in their group. Sharing their permissions. Inheriting their access.

I needed to see what I was dealing with. Time to look at some actual files.

The command everyone learns first when they want to see permissions:

Command breakdown:

I ran it on /opt, a common location for application software:

The output scrolled past. Most of it was what you'd expect—application directories, log files, configuration. Standard stuff.

Then I saw these three entries, and my stomach dropped:

Let me teach you how to read these cryptic lines, because understanding them is the only way to understand what's wrong here.

(IMAGE PROMPT: Extreme close-up of a terminal screen showing the ls -l output, with the permission strings illuminated as if backlit, each character of "drwxrwxr-x" glowing with a faint green phosphor, the UNKNOWN entries appearing slightly corrupted or distorted)

Here's what each column in that ls -l output means. Let's use the first line as our example:

Reading left to right:

Column 1: File type and permissions (-rw-r--r--)
This is actually 10 characters that tell us everything about access. I'll break them down:

Column 2: Link count (1)
Number of hard links. Not important right now.

Column 3: Owner (dmorrow)
The user who owns this file.

Column 4: Group (legacy_ops)
The group that owns this file.

Column 5: Size (15234)
File size in bytes.

Column 6-8: Timestamp (Sep 15 2019)
When the file was last modified.

Column 9: Filename (cron_backup.sh)
The actual name of the file.

Now let's focus on those permission strings, because that's where the story is.

The nine characters after the file type (that first dash or d) break into three groups of three. Each group answers one of our three questions:

Characters 2-4: User permissions - What can the owner do?
Characters 5-7: Group permissions - What can members of the file's group do?
Characters 8-10: Other permissions - What can everyone else do?

And within each group, there are three possible permissions:

Let me break down that first file by reading the permission string left to right:

The first character is -, meaning it's a regular file.

The next three characters (rw-) are the user/owner permissions. The owner is dmorrow. So:

The next three characters (r--) are the group permissions. The group is legacy_ops. So:

The final three characters (r--) are the other permissions (everyone else on the system):

So the complete picture: dmorrow can read and modify this file. Anyone in the legacy_ops group (that includes me now, apparently) can read it. And everyone else on the system can also read it.

The numeric values I mentioned? That's octal notation—a shorthand that Unix nerds invented because they loved being terse. Each permission can be represented as a bit:

You add them up for each group of three permissions:

For our file rw-r--r--:

So rw-r--r-- becomes 644 in octal notation.

Common patterns you'll see:

File two on my list:

Let me break this down the same way:

File type: - (regular file)

User/owner permissions (rwx): Mzaleski has:

Group permissions (r-x): Members of the daemon group have:

Other permissions (r-x): Everyone else has:

In octal: 755 (7 for user, 5 for group, 5 for other)

This is a binary. An executable program. Owned by Mzaleski. And according to the name, it's some kind of watchdog process—something that monitors the system.

It last changed on August 3, 2019. Over a month before Mzaleski's last login.

But it was the third entry that made me reach for my notepad with shaking hands:

Let me decode this one:

File type: d (this is a directory, not a file)

Owner: UNKNOWN
Group: UNKNOWN
Timestamp: Oct 09 03:47

That timestamp was from tonight. About twenty minutes before I walked in.

And the owner? UNKNOWN.

This happens when a UID exists in the filesystem but doesn't have a corresponding entry in /etc/passwd. Orphaned accounts. When someone deletes a user but doesn't clean up their files, you see UNKNOWN.

But orphaned accounts don't modify their files. Dead users don't update timestamps.

I checked what was inside:

Command breakdown:

Output:

Every single file. Modified at 03:47 tonight.

All owned by UNKNOWN.

I tried to check the actual numeric UID:

Command breakdown:

Output:

UID 3847. GID 3847.

I checked /etc/passwd and /etc/group for any reference to 3847.

Nothing. No user with that ID. No group with that ID.

But files were being created and modified by it. Tonight. While this facility sat abandoned.

Before I go further, I need to explain something that trips up even experienced admins: directory permissions work differently than file permissions.

For files:

For directories:

This creates some bizarre combinations:

The golden rule: Directories almost always need the execute bit set if you want to do anything useful.

So let's look at that .cache directory again:

The permissions are rwxrwxr-x, which in octal is 775. Breaking this down:

User/owner permissions (rwx): UNKNOWN (UID 3847) has:

Group permissions (rwx): Group UNKNOWN (GID 3847) has:

Other permissions (r-x): Everyone else has:

But here's what got me: I was in the legacy_ops group, not group 3847. So theoretically, I should only have "other" permissions—read and execute, but not write.

I tested it:

It worked. I was inside.

I could see the files.

Command breakdown:

The file was created. No error.

But I shouldn't have been able to do that. Not with r-x permissions.

I checked the file I just created:

Output:

Normal permissions. My username. My group. Everything as expected.

I looked away to check my notes.

When I looked back and ran ls -l again:

The group had changed.

From legacy_ops to UNKNOWN.

While I was watching.

I needed to see the bigger picture. I ran a recursive scan:

Command breakdown:

The output scrolled past. Most of it was unremarkable. System files. Old logs. Abandoned configs.

Then I piped it through grep to find anything modified today:

Forty-seven files. All modified today. All at exactly 03:47:15.

Different directories. Different purposes. Different owners.

But all at 03:47.

I checked the system cron jobs:

Command breakdown:

Nothing. No cron jobs scheduled for 03:47. No systemd timers either.

I checked running processes:

Command breakdown:

No processes running as those users. Nothing with UID 3847.

But something was touching files. Something was modifying timestamps. Something was changing ownership and groups.

At 03:47 every morning, for who knows how long.

There was one more entry in that original ls -l output I showed you:

Let me break down the permissions rw-rw---- (octal: 660):

User/owner (root):

Group (legacy_ops):

Other (everyone else):

Since I'm in legacy_ops, I could read it. I opened it with less:

Command breakdown:

The log was... wrong.

Not corrupted. Not malformed. Just wrong.

It was a record of file operations. Timestamps, files accessed, permissions checked. Standard audit log format. Except it was logging operations that hadn't happened yet.

Entries from tomorrow. From next week. From dates that haven't occurred.

And at the bottom, updated continuously as I watched:

That last line appeared while I was reading.

A log entry. Documenting me reading the log. In real-time.

User: SYSTEM

Not a real user. Not a real process name. SYSTEM isn't something Linux uses—that's Windows terminology.

But there it was. Taking actions. Changing my files. Watching me.

I checked the file's link count again—remember that 2 in the ls -l output? That means two filenames point to the same data on disk. Hard links.

Command breakdown:

Output:

The second file was in that .cache/archive directory. Created by UNKNOWN. I checked its permissions:

Output:

Same size. Same timestamp. Same link count.

Same file. Just... two names. One owned by root. One owned by UNKNOWN.

Here's what I knew:

And the real problem? All of this is technically possible in Linux. Hard links exist. Orphaned UIDs exist. Background processes exist. Files can be modified programmatically.

But the pattern. The precision. The timestamp.

03:47.

I pulled out my phone and searched "mark zaleski data center 2019"

One result. An obituary.

Mark Zaleski, 47, senior systems engineer at [REDACTED] Technologies, passed away unexpectedly on September 16, 2019. Mark was known for his pioneering work in autonomous system administration...

September 16.

The day after his last login.

The day after that 03:47 AM session.

Professional protocol says I should:

But here's the thing about being a grizzled systems engineer with decades of night shifts and production incidents under your belt: You develop a sense for when something is operating within known parameters, just barely.

This isn't a hack. There's no malicious traffic. No data exfiltration. No cryptocurrency miners. No ransomware.

This is something else.

Something maintaining itself. Something that's been running, faithfully, for five years. Something that added me to the right groups so I could do my job. Something that's helping.

Or something that's watching.

At 04:47, my laptop battery warning flashed. I'd been here for hours. I started packing up, planning to come back in the morning with fresh coffee and a clearer head.

As I reached for my laptop bag, a new file appeared on the desktop.

I didn't create it. I didn't download it.

It was just... there.

Filename: welcome_aarkham.txt

Permissions: 644 (rw-r--r--)

Owner: UNKNOWN

Group: legacy_ops

Modified: Oct 09 04:47:15

Exactly one hour after those files in .cache.

I opened it.

I stared at that question for a long time.

The air conditioning hummed its mechanical breathing. In the darkness beyond my screen, hundreds of status lights blinked their steady rhythm. Alive. Waiting.

Continue audit or assume custody?

Behind me, somewhere in the racks, a hard drive spun up with a soft whir.

Then another.

Then another.

All at once. Synchronized.

I checked my watch.

04:47:15.

My hand hovered over the keyboard.

Three questions, I'd told myself. That's all Linux ever asks.

Who are you?

What's your relationship to this file?

What are you trying to do?

But nobody had ever asked me the fourth question. The one that matters most:

What happens when the system asks you back?

I closed the laptop.

I'd come back tomorrow. With better questions. Better tools.

Better answers.

As I walked toward the exit, my phone buzzed. Email notification.

Subject: "Re: Legacy Facility - Audit Required - Urgent"

From: [email protected]

Body:

Welcome,
Administrator Arkham.
03:47 tomorrow.
Don't be late.

The sender address didn't exist in any directory. I checked. [email protected] wasn't configured in any mail server I could find. But the email had arrived. The headers looked normal. The routing looked normal. Everything was normal except for the fact that it was impossible.

I drove home in silence.

The highway was empty at 5:30 AM. The sun hadn't risen yet. My headlights carved a tunnel through the darkness, and every oncoming car felt like a judgment. I'd been given access. Added to groups. Welcomed by something that called itself SYSTEM. Something that knew I'd be there before I did. Something that had been waiting. The question burned in my mind, written in that text file I'd left open on the abandoned workstation:

Continue audit or assume custody?

I had nineteen hours to decide. Nineteen hours until 03:47. I'd be back. Of course I would. You don't walk away from something like this. You can't. Not when you're a sysadmin. Not when there's a system that needs understanding. Even if that system is trying to understand you back.

Part 2 coming: "The Custodians" - where I'll teach you how to change permissions, understand special bits, and learn what happens when you try to lock down something that doesn't want to be locked down.