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 vorner):

 Looking at the problem from the last report (I guess some old problems
 disappeared and new ones appeared), I'm not sure what to do about them.
 But I
 think this is what happens:
  * The boss starts up. It creates the lock file at early startup, with
 root privileges.
  * Then it switches to the indicated user.
  * Now it starts the msgq. This seems to work in some cases, but if not
    (asuming because of permissions), it would now log (still to STDERR for
 now,
    this should be done in the next sprint). In your output, msgq still
 didn't use
    the logging, so it didn't say anything about it. The boss couldn't
 connect to
    it, because there was no socket file to connect to, but it didn't know
 the
    reason. So, this problem doesn't have to be solved here.
  * If the previous worked, it starts the config manager, which can't read
 the
    config database, so it fails (and correctly complains, so nothing to do
 here
    either).
  * Boss panics and tries to shut down everything. It does so and calls
 exit.
    But then, handling the exit, it tries to remove the lock file. It
 fails,
    since it was created with the root permissions and the current user
 can't
    remove it.

 We could catch it and log properly, but I don't think that is a solution.
 We
 shouldn't leave the file there at all, so we need to think about some
 trick
 here.

 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?

 The other option would be to try and update the permissions when switching
 the
 user. But I think it is the permissions of the directory (not being
 writable to
 the user), not the lock file itself. And I don't think we should tweak
 that.

 Maybe we could examine the permissions before doing the switch and fail
 early
 if we detect we wouldn't be able to delete it at exit. I think we don't
 really
 need to handle the case when someone changes the permissions of the
 directory
 when the boss is running, leaving the exception there, since that'd be
 very
 rare case.

 Any other ideas?

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