3 ms·
> It's worse when working with vendors Well this works the other way around too. I found this especially true when delivering software which is considered an i
by schlowmo 5y ago
> It's worse when working with vendors
Well this works the other way around too. I found this especially true when delivering software which is considered an interim solution.
More than once I got root privileges on customer machines or seen my software run as root because the project owner found it too cumbersome to deal with his own employers security regulations. Or just wasn't given the budget to deal with it properly. Sometimes it's easier to get an exception than to follow protocol.
This is coming back to haunt you if something goes wrong or an interim solution wasn't so interim after all. If someone responsible for auditing permissions asks at this later stage it was always the vendors fault.
- anyfoo 5y agoSome software refuses to run as root. It's far from perfect, and usually easily circumventable, but it might push a lazy admin to at least create a user for your thing or similar.
- franga2000 5y agoI hate that as a solution. I've had strange issues with software that I couldn't debug, but when I ran it as root in a test VM, it worked instantly. So I immediately knew it was a permission issue and started digging through the docs for a list of files it needed access to. I then fixed the permissions for it and ran it without root in production. If the software limited me to not running as root, I would have probably spent far longer debugging other issues and digging through 100s of lines of strace output.
- mauvehaus 5y agoI think all software should come with the --räikkönen[0] --here-there-be-dragons --yes-i-mean-it set of switches to enable you to do boneheaded stuff when needed. And using them in prod should be grounds for dismissal, or at least pretty severe legal liability if things go wrong as a result. [0] https://m.youtube.com/watch?v=F3d_Cu5Mzbk https://m.youtube.com/watch?v=F3d_Cu5Mzbk
- franga2000 5y agoI really like that idea, actually. Have a blanket "no safety checks whatsoever" flag, but in the ToS it invalidates all warranty and support requirements if in use. This would also make it really obvious in court who was negligent in case of a security breach, since something like "running as root is bad practice" is a lot less clear to a non-technical judge than "they explicitly enabled a flag called --i-know-this-is-insecure-do-it-anyways", even though the issue (running as root) was the same.