-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At SC13 a few of us were talking about the issue about what to do when you have to allow users to SSH into nodes where there jobs are running.
Currently SLURM doesn't put SSH sessions permitted by the current pam_slurm module into any control groups, it would be nice if it would at least put them into the top level /cgroup/cpuset/slurm/uid_$UID for the user so they can only affect their own jobs. The problem is that With SSH's privilege separation the current SLURM PAM module cannot do this as it will run as an unprivileged process (not the user) prior to authentication and so cannot have the permissions to move processes around. However, it appears that something like a pam_slurm *session* library would (I believe) run as the user in question - as long as it it can learn the PID of the shell being spawned. The problem then is how to allow that to securely put itself into the users top level cgroup. If slurmd just made the tasks file for that top level cgroup owned by the user then the process could do it, though there would be a small risk that the user could then move processes from lower, insulated containers into the top level, though they'd only be affecting their own stuff. Thoughts? All the best, Chris - -- Christopher Samuel Senior Systems Administrator VLSCI - Victorian Life Sciences Computation Initiative Email: [email protected] Phone: +61 (0)3 903 55545 http://www.vlsci.org.au/ http://twitter.com/vlsci -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLE/D4ACgkQO2KABBYQAh9PTACfe4qXrZTMfeWts5X+JtJyHtW6 oigAoI6ZMJIf3k3PTcVH0/QwnNWTIzzr =QOW8 -----END PGP SIGNATURE-----
