Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Tor Tor
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 340
    • Issues 340
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 34
    • Merge requests 34
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Core
  • TorTor
  • Issues
  • #40382
Closed
Open
Issue created May 07, 2021 by Nick Mathewson@nickm🤹Owner

Sandbox failures with glibc 2.33

It appears that glibc 2.33 is using yet another new set of system calls to implement our old friends. In particular I'm seeing newfstatat used to implement both stat and fstat.

Incidentally, this change will probably mean that we can't allow fstat() without allowing all stat() calls in the sandbox, since the behavior of using fstatat to implement fstat or seems to depend on the presence of AT_EMPTY_PATH and on having an empty string for the path argument, and we can't detect a glibc-generated empty string from the seccomp sandbox.

So, how bad is it to allow all stat() calls from the sandbox? Probably it's not so great, but I don't see a choice here.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking