>Have them go reread the man page on specifying commands and associating them with keys.
Visa and MasterCard mandate that direct superuser access will not be allowed remotely. In other words, their auditors must see the line “PermitRootLogin no” in our sshd configs. Our security guys have very little say in that respect.
>oh? I don't know anything about running Xen. But I fail to grasp the rationale behind denying both SU or logins as root. It sounds like the "security" people can't tell the difference between real security management and somebody's >naive policy assertion. It's rather telling that they think some home-grown application is a more secure/acceptable solution.
It’s not su- that’s disabled. The obvious reason I was speaking of is the authentciation after su – is invoked. Given the following shell script excerpt;
ssh nobody host –c “su -; xm shutdown domain3”
We can’t very well pass the root password to su with expect, that’s just bad practice in anyone’s book. Neither can we allow nobody to su without authentication, that’s even worse practice.
Making xm setuid and protecting it with RBAC controls is not an option either, beause xm is a python script. I would have to make python setuid, and that’s the worse scenario yet.
So it seems that a small daemon running on the xen host that receives a request from a fence agent, then makes the appropriate libvirt call to destroy the instance is both relatively simple while remaining secure.