user sessions inoperative for recreated user with same uid

[James Hunt]

I suspect the incidence of users hitting this problem is low, but
nonetheless the issue needs to be resolved since it actually comprises two bugs.

If a user creates one or more user jobs, the user is then deleted (along
with their home directory), but is subsequently recreated with the same
uid prior to a reboot, user sessions will be implicitly disabled for
that user. That is to say:
______________________________________

# useradd -m foo -u 1234
# su - foo
$ id -u
1234
$ mkdir ~/.init/
$ cat >~/.init/foo.conf<<EOT
exec /bin/true
EOT
$ start foo # OK
$ exit
# userdel -r foo
# useradd -m foo -u 1234
# su - foo
$ id -u
1234
$ mkdir ~/.init/
$ cat >~/.init/foo.conf<<EOT
exec /bin/true
EOT
$ start foo # FAILS
$ exit
______________________________________

This problem is caused by a combination of two issues:

- Upstart does not have the ability to destroy a ConfSource object.

  This may sound strange, but until sessions were introduced, ConfSource
  would always persist for the duration of a single boot.

- NIH does not currently have support for removing an inotify watch.

The bug is triggered therefore when the newly-recreated user causes a
new session object to be created. This triggers the creation of a new
ConfSource object via session_create_conf_source(). However, although
conf_source_reload() is called to create the inotify watch on the users
home directory, there is already a stale inotify watch on the *same*
directory path* but which is now effectively "dead".

The stale (and wholly inoperative) watch effectively blocks subsequent
watches on the same directory since nih_watch_add() checks for duplicate
paths and thus silently ignores the request to create a new watch on a
path it already knows about.