Bug 2380 - [PATCH] Optionally allow pam_setcred to override gid
Summary: [PATCH] Optionally allow pam_setcred to override gid
Status: NEW
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: PAM support (show other bugs)
Version: -current
Hardware: All Linux
: P5 enhancement
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-14 04:19 AEST by Ryan Cox
Modified: 2015-10-28 07:50 AEDT (History)
0 users

See Also:


Attachments
openssh_permit_gid_override.diff (8.45 KB, patch)
2015-04-14 04:19 AEST, Ryan Cox
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Cox 2015-04-14 04:19:56 AEST
Created attachment 2583 [details]
openssh_permit_gid_override.diff

I would like to allow pam_setcred/pam_sm_setcred to override the gid that is normally set for a user.  Currently the openssh code calls do_pam_setcred then it sets the gid to the user's gid as listed in /etc/passwd, LDAP, or whatever regardless of what the pam module set it to.  I would instead like a pam module to be able to set the gid with setgid() and not have it overwritten by openssh.

I wrote a patch that does just that by comparing getgid() before and after calling do_pam_setcred.  If the gid changes it sets pw->gid to the new gid, which is used in later functions.  I don't know if this is considered the proper way to achieve that behavior in a safe way but it seemed logical to me.  The behavior is optional; PermitGidOverride=no is the default.

As for the reasoning, this is for a scheduled environment using Slurm.  I am developing a pam module that "adopts" ssh processes into the appropriate batch job on the node.  Users can launch jobs via Slurm that run with their gid as one of their supplementary groups.  As part of the adoption of the ssh process, I would like to set the ssh process's gid equal to that of the job it is being adopted into.

Ryan

(I also posted this to the dev list but I figured I should add it here for tracking purposes)
Comment 1 Ryan Cox 2015-10-28 07:50:21 AEDT
Any thoughts on this?