Security is challenging to get right. It's always a complex balancing act between what users want and what administrators need. Between placing the server in a hermetically sealed container with no cables running the outside world, and setting the server up on the busiest street corner in town with an already logged-in administrator account pulled up on the attached monitor. Depending on the O/S update policy in practice at your company, that last example can be roughly the equivalent of connecting your server to the Internet.

Here at TDWTF, security is a common topic of submissions. If only because there are so many different (and creative) ways to set things up that are wrong and only a couple of ways to set it up that are correct. And there is a non-zero percentage of administrators that are, shall we say, less than diligent in how they go about their job. We're sure that none of you fit into that category. We're talking about other people.

So with that in mind, consider Jim's plight.

For the past year, Jim had been working, along side a group of foreign developers, on a Magento installation. The reasons for the length of the project could be the result of a number of happenstances. Maybe it was the fact that requirements had the malleability of the an un-fired lump of clay. Perhaps it was the challenge of translating these requirements into sufficiently concise and clear descriptions to be passed off to the foreign development team. Or, just perhaps, some of the company's own policies (or anti-policies) got in the way.

The current goal was to move a recently completed module to the production server. Under normal circumstances (for those of you who are not Magento-familiar), this is a routine and straightforward task. However, this was not the case for Jim. Once deployed, the new module did not appear in the Magento customization panel. And Jim could no longer view the Permissions panel.

The quite reasonable conclusion is that there was a problem with security. A problem that hadn't existed at the time of the last module deployment, since it was, you know, successful and all. So Jim went directly to the super-admin user.

The response was mildly surprising. Jim was told that his permissions had been restricted. At the request of management.

Huh? Okay then. Next stop: management. Jim went to his manager and asked what, if anything, he knew about the request. Turns out that he did.

A few days earlier, Jim's manager was unable to delete a test order. His belief (through his black-and-white-colored manager glasses) was that Jim must have changed something. So he made the request to the administrator that he be given full access. And the Jim have his permission reduced.

Deep breath. After all, this wasn't the first time.

"But when it comes time to deploy and enable modules, I need to have administrator permission", responded Jim.

"You can get the super-admin user to do that. No need for you to have those privileges."

"Well, yes. But that will delay things. And doesn't really do much for security, as I have full access to the source code, server and database."

As an aside, it's rarely good to argue that you should be given a security exemption by suggesting that if you wanted to screw the company, it was already within your power to do so. Just keep that in the back of your mind as you move through your career. Now, back to our story.

"Just do what I ask", was the not unexpected reply.

Being the good corporate citizen that he was, Jim followed his manager's instructions. He sent his request to the administrator and waited a couple of days for it to be fulfilled. As it turns out, when the super-admin user deployed the module, he too was unable see the Permissions panel in the Magento console. So, to help troubleshoot the problem, Jim was temporarily given full access to the system.

If this isn't irony, it's pretty close.

As Jim was looking at the dog's breakfast that was the permissions allocated to each role, Jim noticed that his manager didn't actually have full access. The administrator had only restricted Jim without actually increasing the manager's capability. And that neither of them belong to the role that would allow them to deploy modules to the Magento installation. That ability, based on Jim's digging, seemed to reside solely in the persona of Montgomery.

Montgomery was the WordPress designer. While Jim was responsible for the customization of the modules and implementing additional functionality on the server side, Montgomery was in charge of the design of the site. In terms of the access he required on the server, it could have been limited to the theme folder and maybe some XML files. But he was not a framework coder, nor could he build a module on his own. In other words, his need to have full access ranged from minimal to non-existent.

So Jim is faced with a collection of options, none of which were good. He could send every one of his future production requests to the administrator, wait the day or two for it to be acted upon and deal with the delays in scheduling that causes. He could make a request to his manager, one that had already complained that Jim's permissions were too high, to increase his privileges. Or he could talk Montgomery through the steps necessary to get his modules and other updates installed.

Suggesting that facing options like this was a Sophie's Choice is going over the top. Instead, Jim preferred to think of it as a Full Monty.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!