When the tension between privileged access and security gets unpleasant, how do we deal with it? ''From an online security forum:'' Is there anyone who would be willing to share their experiences on how they or their organization have handled the situation where developers have been challenging the organization's policies on roles and responsibilities and/or separation of duties? I am finding that developers are becoming more aggressive about having complete access (root access) to their development area ''(system instance, not workstation)'', citing business imperatives. It seems to be particularly prevalent within web development, where both access rights and standards are challenged. We have a small team supporting this and attempting to stand their ground, but it is not easy. The in-fighting creates a negative work environment that effects the productivity of all involved and could potentially impact the security of the environment. I would be appreciative to hear from anyone who has successfully managed this dynamic. ''What advice would we give him?'' -- MarcThibault 2010-09-17 ---- ---- Figure out what it is that they need that they think getting root access will give them. Then find a way to give them that without giving them root access. In particular, could it be solved by private instances of programs? One example of such is a web server running against their local configuration file, and listening on a port in the non-privileged range. Similarly, local database areas. Sometimes this will be enough. ---- I have always been a programmer, rather than an admin. But, I preferred to have typical users access, rather than root access, because I didn't want to be accused of causing or allowing a security breach. On the other hand, admins were sometimes incapable of provisioning my PC on-time with the features and tools I needed, which frustrated and angered me. I couldn't do my job and had to twiddle my thumbs while waiting for an admin to learn their job. As a day or two passed without a PC to use, my schedule slipped, and a difficult schedule became impossible. It is a difficult position for one to endure, and some people will demand root access so they can do something proactive. There will be users who just want power over their PC, a management directive stating they cannot have it should be sufficient. If the reason users want more power is pragmatic, then management has failed to allocate adequate admin resources. In any case, it is a management problem that requires an informed and reasoned management solution. Yelling and threatening is seldom successful. -- EdwinEarlRoss ---- One solution is to mount a virtual machine which the developer can use, with power to mount different version of software as needed (which will usually mean root access on linux). I already do this myself on a laptop where I can mount what I like. When I was offered similar access at work, I said ''Yes, please I would like Fedora.'' to which the answer is ''We supply CentOS as it is more stable.'' In this case ''more stable'' translates to ''three issues earlier of the gcc compiler'' which is not a lot of use to explore e.g. recent developments in C++. I think one sort of system is good for production delivery of services, and quite a different one for those exploring the future, where an update of the system every six months is not a big disadvantage. There is often a problem in keeping the dialogue open between administration and innovation. -- JohnFletcher ''In universities, that dialogue is often facilitated by allocating a portion of your research funding to IT support. In its absence (unfunded research), expect a cost-minimizing standard of service unless you've made an effort to foster personal relationships with the IT support team.'' ---- Cries of help from the Dilbert Universe: Perhaps the developers wonder why bumbling admins deserve root access but not business-critical programmers. It implies admins are better than developers. If it's that kind of psycho-socio-political tinged-with-role-prejudice issue, no matter how much root-like capability you give the developers it won't be enough until it's genuine root access. Of course, that's not an acceptable solution. There's probably a single ringleader driving the developers' dissent. Identify and fire that individual. Most developers are passive and submissive; they will toe the line once their leader is removed. Withdrawal of perks & privileges whilst increasing workload and working hours -- along with subtle threat of reprisals and dismissal -- will further subjugate them and keep them sufficiently occupied to virtually eliminate further annoyance. If possible, sack the entire development team. The weak economy and high unemployment figures mean replacement programmers are now available at bargain prices. In some cases, new graduates will work for free in order to gain experience; promises of eventual payment can sometimes be strung out for years, especially if poor performance reviews are used to modulate self-esteem downward whilst maintaining a usable degree of long-term striving. ''I have found that root access *on my own workstation* is so imperative for development that if I can't get it through channels I will either breach workstation security (easy to do) or do all work from within a qemu instance. Any developer not competent to admin his own workstation (a single use box!) is not competent to be a developer. End of story.'' ---- CategorySecurity CategorySecurityModel