Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 527
    • Issues 527
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 96
    • Merge requests 96
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container 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
  • ISC Open Source Projects
  • BINDBIND
  • Issues
  • #551
Closed
Open
Created Sep 21, 2018 by Cathy Almond@cathyaDeveloper

[ISC-support #13429] Improve named's ability to run suid and/or with setcap

Description

named's behaviour when started suid (as opposed to launched by a user with root privileges) can't be relied upon to work consistently. It may work when named is single-threaded, but fail to open the server sockets if named is running multi-threaded.

Request

There have been several threads on this topic over the years. named was not coded to take into account all the variants of privileges and capabilities, and adding in the different implementations for multithreaded support and the need to manage privs across multiple threads/processes has made it difficult to control BIND from secure appliances or utilities such as systemd.

Please could we consider the above problems (and see the links/references below for further material) when we next visit how named handles capabilities and privilege dropping code.

If not all of the 'expected' variants on uid/privs will work, then a document explaining what will and won't work, and precisely why, would be much appreciated, to complement any best practices advice that we also offer.

Links / references

References: #321 (closed) https://lists.isc.org/pipermail/bind-users/2015-September/095758.html https://lists.isc.org/pipermail/bind-users/2018-January/099437.html https://support.isc.org/Ticket/Display.html?id=11942 https://support.isc.org/Ticket/Display.html?id=11470

Assignee
Assign to
Time tracking