Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LocalProcessSpawner preexec problems: groups not set, pam session wrong scope #4726

Open
clhedrick opened this issue Mar 12, 2024 · 3 comments
Labels

Comments

@clhedrick
Copy link

clhedrick commented Mar 12, 2024

Bug description

Two problems with the preexec passed to Popen when starting the single server:

  • If you are using IPA for user/group management, only groups defined in /etc/groups are set, not those that come from LDAP
  • If you ask for a PAM session, it puts the top level jupyterhub process in the session, not the single server

For the first, rather than

gids = [g.gr_gid for g in grp.getgrall() if username in g.gr_mem]

in the wrapper, do

       os.initgroups(userent.pw_name, userent.pw_gid)

in the preexec function itself. Initgroups uses undocumented internal libc calls to get just the groups for that user, and is thus much more efficient than getgrall for sites with many users and groups. It also works properly with IPA.

For the second, put the

       pamela.open_session(userent.pw_name,service='jupyterhub')

in the preexec function, not the authentication code.

Here's my actual code, from jupyterhub_config.py

class LocalProcessSpawnerEnv(LocalProcessSpawner):

    async def start(self):
        myuser = self.user.name

        def mypreexec():
           userent = pwd.getpwnam(myuser)
           pamela.open_session(userent.pw_name,service='jupyterhub')
           os.initgroups(userent.pw_name, userent.pw_gid)
           os.setgid(userent.pw_gid)
           os.setuid(userent.pw_uid)
           try:
              os.chdir(userent.pw_dir)
           except:
              pass

        self.popen_kwargs = dict(
           preexec_fn = mypreexec,
           start_new_session=True,  # don't forward signals                                                                
        )

        # actually start the process                                                                                       
        startret = await super().start()

        return startret

How to reproduce

  1. Go to '...'
  2. Click on '....'
  3. Scroll down to '....'
  4. See error

Expected behaviour

Actual behaviour

Your personal set up

  • OS:
  • Version(s):
Full environment
# paste output of `pip freeze` or `conda list` here
Configuration
# jupyterhub_config.py
Logs
@clhedrick clhedrick added the bug label Mar 12, 2024
Copy link

welcome bot commented Mar 12, 2024

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.
welcome
You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

@minrk
Copy link
Member

minrk commented Mar 19, 2024

The PAM sessions being wrong is already open at #2973, documented, and why sessions are off by default.

#4628 may already fix the other issue, though it calls os.getgrouplist instead of os.initgroups, which sounds like it might be better. Would you like to make a PR for that?

@minrk
Copy link
Member

minrk commented Mar 26, 2024

If anyone has a Dockerfile where PAM sessions open and close actually do things, that would be a huge help for testing this kind of thing. I tried setting up a simple toy with pam_python, but I can only get it to segfault, not actually do anything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants