[Bug 2380] New: [PATCH] Optionally allow pam_setcred to override gid

bugzilla-daemon at mindrot.org bugzilla-daemon at mindrot.org
Tue Apr 14 04:19:56 AEST 2015


https://bugzilla.mindrot.org/show_bug.cgi?id=2380

            Bug ID: 2380
           Summary: [PATCH] Optionally allow pam_setcred to override gid
           Product: Portable OpenSSH
           Version: -current
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: PAM support
          Assignee: unassigned-bugs at mindrot.org
          Reporter: ryan_cox at byu.edu

Created attachment 2583
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2583&action=edit
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)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


More information about the openssh-bugs mailing list