CODE IN TOKYO

Unreasonable Security Rules Push Engineers to Hunt for Loopholes — A Tale of FTP Hell 20 Years Ago

It’s been nearly 20 years now, so I figure the statute of limitations has run out. Time to write this one down.

Back then, I was developing a web system for a client. The environment was, let’s say, intense.

You could only upload files via FTP. And realistically, only PUT was allowed.

You couldn’t check directories. You couldn’t log in to the server. You couldn’t see the Apache config. And it wasn’t just production — even the dev environment was the same.

In other words:

A literal hell.

From our side, all we could say was:

“It works locally.” “But we know nothing about the server.”

Meanwhile, the IT (info-sys) team managing the server took the stance:

“We won’t let you touch the server.” “But make it work.”

Looking back, the responsibility boundary was completely broken on this project.

What made it worse: the client’s on-site staff were also stuck. They wanted to push development forward, but they couldn’t bend rules owned by another department.

So the field started doing what the field does. We began hunting for loopholes.

Technically, the rule only restricted what could be uploaded via FTP — not what those PHP files did once deployed. Meaning: if you could put a PHP file there, you could execute commands on the server.

So eventually, we uploaded something we called an “environment research PHP” to inspect the Apache configuration, paths, and module status.

Of course, we had the client contact’s agreement. But rules-wise, it was very gray — probably out.

But the field was already in panic mode.

We said: “We can’t run this without server info.” IT said: “Not our jurisdiction.” The client said: “But the release date is fixed.”

Looking back, I suspect the IT team had only imagined “an operation where you place HTML files.”

So their mental model was:

“You can upload via FTP” ↓ “Therefore no problem” ↓ “If it doesn’t work, that’s the app’s problem”

But the moment you have a PHP application, it depends heavily on:

— all server-side elements.

Black-boxing all of that and saying “run it at your own risk” is a stretch.

To be a little mean about it, I even suspected:

“Maybe the IT team couldn’t log in to the server either.”

The server might have been fully outsourced, with every inquiry costing money. That kind of structure.

Of course, the right move would have been to align internally before taking on the project. But when departments differ, this kind of thing really happens.

Sales sells. The field builds. IT defends.

And no one looks at the global optimum.

In the end, we somehow figured out the Apache configuration and got it running.

Internally, of course:

“Why did we even take this project…”

That was the natural reaction.

And now, 20 years later, while writing this blog, my suspicion has turned into conviction.

The IT team probably couldn’t log in to the server either.

So it wasn’t “we won’t let you touch it” — it was “we can’t touch it” themselves. We weren’t fighting them. We were standing in the same fog together.

Every time I hear about a security incident in the news, I think:

— That “environment research PHP” we uploaded back then… it’s not still quietly running on that server, is it?

No way. We deleted it. Probably.

…probably.