Hacker News new | past | comments | ask | show | jobs | submit login

I suspect that it's more common than you'd guess.

In one situation I was working for a supplier to a massive corporation (a household name). They had all sorts of red tape in the process. Every change required filling in forms and getting official sign off from several parties before getting the release code over.

Anyway, we had a database user that was so restricted the we couldn't run the install process of a new product. I knew they ran the releases as SA so the start of my release script upgraded all the permissions of our user to give full access to everything.




I guess its very common, but this is a financial institution.

What you describe as a solution strikes me as an amazing way to destroy production data. Upgrading every user can basically lead to one hell of an amazing outside attack. I now only have to get one user / password to compromise your database.

A certain amount of red tape is a needed thing to make sure you don't affect your customer's business.


True, I didn't stop to consider the financial aspect.

Was more just pointing out that there's often this separation between the people making the changes and the people making sure it's safe to release. But really, the safe to release step is often not going to catch things – in many cases because it's barely checked.

To be fair, I only upgraded my user to give full access to my db and I revoked the permissions once the install script had finished running. I'm not a complete monster :-)


Good... deploys are a strange world sometime.

I just didn't want to hear that you had set yourself up for a CEE (career ending event). People tend to be a tad bit wacky and whacky after a security breech.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: