user sessions inoperative for recreated user with same uid
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
upstart |
New
|
Undecided
|
Unassigned |
Bug Description
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/
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/
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_
conf_source_
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.