Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • D dbus
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 262
    • Issues 262
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 32
    • Merge requests 32
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • dbusdbus
  • dbus
  • Issues
  • #274
Closed
Open
Issue created Aug 12, 2019 by Philip Withnall@pwithnallReporter

Add GetConnectionUnixProcessIDHandle method

Since the kernel has gained more support for pidfds, Will Thompson suggested that it would be useful if D-Bus gained support for a GetConnectionUnixProcessIDHandle method to return one. This would be analogous to GetConnectionUnixProcessID, but would return a pidfd (type h) rather than a PID.

This would only work on Unix, and only on kernels which support pidfds. It would return an error if pidfds aren’t supported by the kernel, and callers would presumably have to fall back to calling GetConnectionCredentials or whatever they used to do.

On success, the returned pidfd would remain open until the caller explicitly closed it, and could be used to track the remote peer without the usual race conditions relating to PID reuse.

The use of pidfds might potentially provide a way to reliably(ish) identify peer processes without needing an LSM, which is a typical roadblock to implementing that feature on many Linux systems (since many Linux systems don’t have LSMs). While it won’t make any of the information you can look up about a process more reliable, it will mean that a peer can at least be sure it’s looking up the right process.

Assignee
Assign to
Time tracking