BIND 10 #711: starting to use --user

[BIND 10 Development]

#711: starting to use --user
-------------------------------------+-------------------------------------
            Reporter:  jreed         |                        Owner:
                Type:  defect        |                       Status:  new
            Priority:  medium        |                    Milestone:
           Component:  Boss of BIND  |  Sprint-20130108
            Keywords:                |                   Resolution:
           Sensitive:  0             |                 CVSS Scoring:
         Sub-Project:  Core          |              Defect Severity:  High
Estimated Difficulty:  3             |  Feature Depending on Ticket:
         Total Hours:  0             |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:13 vorner]:

 > I think we're having some trouble with the lock file in other places, so
 it
 > would be nice to come up with a way to synchronise without the file. Are
 there
 > some kind of inter-process semaphores?

 Not exactly the same point, but I've never been a fan of re-inventing
 such low level things as file locks ourselves, so I'd be glad if we
 can replace it with something like
 boost::interprocess:interprocess_semaphore

 That aside...assuming we cannot get rid of the file lock soonish, I
 think there's at least one issue that would be better fixed as a short
 term matter: consider the following install/startup scenario:
 {{{
 % cd bind10-1.0.0
 % ./configure
 % make
 (% make check)
 % su
 # make install
 # /whatever/path/sbin/bind10 -u bind
 }}}

 This is one common operational practice, but it will fail for several
 reasons, including the lock file permission.  The problem is that it
 wouldn't be very clear what was wrong from log messages.

 So, for this task, I suggest making it clearer that there's a file
 (directory) permission issue and it should be fixed before starting
 BIND 10 in the above scenario.

 One possible idea is to try to create a separate logger (and use it)
 immediately after switching the user:
 {{{#!python
         if self.__uid is not None:
             #logger.info(BIND10_SETUID, self.__uid)
             posix.setuid(self.__uid)

             # We use one-shot logger after setuid here.  This will
             # detect any permission issue regarding logging due to the
 result
             # of setuid at the earliest opportunity.
             isc.log.Logger("boss").info(BIND10_SETUID, self.__uid)
 }}}

 And, maybe catch an exception from it like the main bind10_src does:
 {{{#!python
     # Announce startup.  Making this is the first log message.
     try:
         logger.info(BIND10_STARTING, VERSION)
     except RuntimeError as e:
         sys.stderr.write('ERROR: failed to write the initial log: %s\n' %
                          str(e))
         sys.stderr.write("""\
 TIP: if this is about permission error for a lock file, check if the
 directory
 of the file is writable for the user of the bind10 process; often you need
 to start bind10 as a super user.  Also, if you specify the -u option to
 change the user and group, the directory must be writable for the group,
 and the created lock file must be writable for that user.
 """)
 }}}

 In the above case, maybe we should raise a separate exception and let
 the main code catch it and dumps detailed message like that.

 Coincidentally, if the administrator fixes the directory permission,
 it also solves other possible problems like opening UNIX domain socket
 for msgq because these use the same directory by default (and, for this
 ticket, I think it suffices to fix the default case.)

-- 
Ticket URL: <http://bind10.isc.org/ticket/711#comment:14>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development