Repository navigation
create debugger tmp directory with 0o700 permissions - #1530
Merged
Merged
Conversation
JohanMabille
approved these changes
Jun 15, 2026
JohanMabille
added a commit
that referenced
this pull request
Oct 17, 2026
Debugger.start only creates its scratch directory when Path(tmp_dir).exists() is false, and get_tmp_directory returns the completely predictable <tempdir>/ipykernel_<pid>. Path.exists follows symlinks, so on a host with a shared temp directory another local user can reach that name first and point it at a directory they own; the kernel then skips the mkdir, the 0o700 mode from #1530 never applies, and dumpCell writes the cell source straight through the link. I went back to start after that permissions change and noticed the mkdir is reachable only when the path does not already exist, which is the one case someone else gets to control. Planting the predictable name as a symlink locally confirmed it: start carried on, dumpCell dropped the cell text into the other directory, and a symlink planted under the Murmur2 cell name turned the same write into an overwrite of a file outside the temp tree. Creating the directory first and only accepting an existing one when lstat says it is a real directory owned by this user closes that, and opening the dumped cell with O_NOFOLLOW keeps the file write itself from being redirected; the cell file now lands at 0o600 instead of whatever the umask gives, matching the directory around it. Added two regressions beside the existing debugger tests, both skipped when debugpy is absent and on Windows where symlinks need privileges and O_NOFOLLOW does not exist.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
While looking at where the debugger persists cell sources, I noticed
Debugger.startcreates the scratch directory withPath(tmp_dir).mkdir(parents=True)and no mode argument.get_tmp_directory()returns a predictable<tmpdir>/ipykernel_<pid>, so on a typical umask the directory lands at 0o755 and the cell filesdumpCellwrites into it come out 0o644. On a shared host any other local user can then read the source the user is debugging. Checking the mode locally confirmed 0o755 on the directory and 0o644 on the written.pyfiles.The connection directory in
kernelapp.init_connection_fileis already created withmode=0o700for the same reason, so this brings the debugger scratch directory in line. Setting the mode at creation keeps the restriction next to the only place the directory is made, rather than relying on the ambient umask being tight.