Package: sudo Version: 1.9.8p2-1 Severity: important This is a regression compared to 1.9.5. Reproduction: As root, run:
sudo -u nobody bash Expect: # sudo -u nobody nobody@foobarxyz:/root$ Does: # sudo -u nobody bash sudo: unable to resolve host foobarxyz: Name or service not known sudo: error initializing audit plugin sudoers_audit This is with /etc/sudoers containing root ALL=(ALL) ALL So no lookups should be required. Note: "host non-resolving-hostname" must actually not return a result. If the hostname is not resolvable locally but resolvable via DNS, this issue does not occur. Same setup with sudo 1.9.5p2-3 leads to: root@larsa:~# sudo -u nobody bash sudo: unable to resolve host foobarxyz: Name or service not known nobody@foobarxyz:/root$ I tried figuring out which change exactly caused this, but I'm actually lost in the source code. But from a search on bugzilla.sudo.ws, this seems to essentially be https://bugzilla.sudo.ws/show_bug.cgi?id=1016#c3 However: root@larsa:~# hostname foobarxyz root@larsa:~# sudo -u nobody bash sudo: unable to resolve host foobarxyz: Name or service not known sudo: error initializing audit plugin sudoers_audit root@larsa:~# grep fqdn /etc/sudoers Defaults !fqdn root@larsa:~# root@larsa:~# hostname larsa root@larsa:~# sudo -u nobody bash nobody@larsa:/root$ exit So like Himanshu on that bug, I'm unable to disable the fqdn option, it seems or it doesn't have the influence Todd C. Miller thinks it has. I suspect that the default change via sudoers is only read after the audit. And indeed, compiling 1.9.8p2-1 without --with-fqdn option would fix the regression, but I think the real fix is somewhere in the code. It is _wrong_ for the audit plugin to run into this error. See also https://bugzilla.sudo.ws/show_bug.cgi?id=1016 -
