Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • D dynamorio
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,467
    • Issues 1,467
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 44
    • Merge requests 44
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • DynamoRIO
  • dynamorio
  • Issues
  • #1716
Closed
Open
Issue created Jun 30, 2015 by Derek Bruening@derekbrueningContributor

auto-redirect private library file opening to use private descriptors

DR provides isolation of file descriptors for files opened by DR and clients, which is important for transparency and proper execution of shells and other applications.

However, when writting clients that use libraries, in particular C++ clients, it is convenient to use things like fstreams to deal with files. Yet this results in descriptors in the application space. Additionally, when writing code shared between clients and standalone apps, it can be painful to support both regular file behavior and private file descriptors (e.g., see drcachesim's named_pipe implementation, which resorts to a separate set_fd() and separate usage code in the client).

Can we make these various file open routines auto-redirect to private fd's? (If so we should update named pipe usage: no set_fd() needed.)

One potential issue is that os_open_protected() ends up using heap and thus grabs locks. This should be ok as neither clients nor 3rd-party libs should hold higher-ranking locks.

Assignee
Assign to
Time tracking