Summary: | net-dns/bind-9.6.1_p2 changes owner of existing files | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Simon Arlott <bugzilla.gentoo.simon> |
Component: | Current packages | Assignee: | Konstantin Arkhipov (RETIRED) <voxus> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bind+disabled, henson, notordoktor, qa |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 302361 | ||
Bug Blocks: |
Description
Simon Arlott
2010-01-17 12:56:57 UTC
9.6.1_p3 does this too, why has it not been fixed? (In reply to comment #0) > The ebuild for bind keeps running a recursive chown on /var/bind, changing the > user to named for all files. It probably does so b/c there's stupid inconsistency in portage regarding dealing with preserving of permissions between files and directories so this sort of hacks is spread all across the tree to make thing works, instead of producing obscure hard-to-reproduce bugs depending on whether it's an upgrade, reinstall or fresh install and customized by user or not. See Bug 141619 and any complaints in this regard should be IMHO directed there to produce some action on package manager side finally. Doing something in ebuilds makes no sense until the PM has a consistent and well defined behaviour. (In reply to comment #2) > See Bug 141619 and any complaints in this regard should be IMHO directed there That bug is only concerned with directory permissions, so this ebuild's chown could be modified to only affect directories and avoid changing ownership of all my files. (In reply to comment #3) > That bug is only concerned with directory permissions, so this ebuild's chown > could be modified to only affect directories and avoid changing ownership of > all my files. Huh? How does that solve anything? It'd break even more stuff. Either the permissions are correct and consistent across the board for both dirs and files (so that the user/group BIND runs as can do its work) or not. What exactly are you trying to do here with the permissions? The suggestion doesn't make any sense. I was about to file this exact bug. I modified the permissions in /var/bind to meet the requirements of a zone file management application we developed, and it was completely broken when we installed a new version. I can't comment on the other bug referred to, but it's simply wrong to blindly change the permissions configured by the system administrator. It doesn't look like this is going to be resolved anytime soon, so I'm just going to switch to /var/lib/bind as the location for my zone files. /var/lib is where app db files typically go anyway. Fixed in bind-9.7.0_p1 |