BIND 10 #1508: Move dropping root into sockcreator startup
BIND 10 Development
do-not-reply at isc.org
Tue Jan 10 07:44:30 UTC 2012
#1508: Move dropping root into sockcreator startup
-------------------------------------+-------------------------------------
Reporter: | Owner: jinmei
vorner | Status: reviewing
Type: task | Milestone:
Priority: | Sprint-20120110
blocker | Resolution:
Component: Boss | Sensitive: 0
of BIND | Sub-Project: Core
Keywords: | Estimated Difficulty: 4
Defect Severity: N/A | Total Hours: 0
Feature Depending on Ticket: |
Socket creator |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Comment (by jinmei):
Replying to [comment:9 vorner]:
> Considering the code will disappear soon (as we talked about today, when
we make the socket creator setuid-root, it won't be needed), should I
write a version that moves the pseudocomponent, or should I merge it like
it is? It still should be merged (or changed), otherwise the other two
tickets will make everything run as root for now.
I thought we'd still keep the -u option for the boss (so we can still
run it as a non root even if the OS's startup framework doesn't
support the ability to specify the user explicitly, without requiring
the administrator to prepare a special script or something). Would we
do this in the very initialization part of the boss then (which is
fine to me btw)?
Assuming we provide the capability of -u somehow, and the "workaround"
of this branch will be removed as a result of that, I'm okay with that.
> I don't like the idea with yet more granular startup, the boss should
know as little about the components as possible.
I disagree: IMO where to change the user (when necessary) should be a
decision at a higher level than a particular component (in this case,
which is specifically the socket creator component). That would be
the main boss itself if we hardcode these special components as we do
now; if we even fully generalize the special things, that would be a
matter of user configuration.
But, depending on how we do -u in the post setuid era, the
disagreement on this point won't be an issue any more. And, if so,
I'd simply drop this part of this discussion.
--
Ticket URL: <http://bind10.isc.org/ticket/1508#comment:10>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list