[PATCH] fill_user_info: fake user info for 'root' if it can not be found

Simon McVittie simon.mcvittie at collabora.co.uk
Tue Feb 26 04:11:30 PST 2013

On 25/02/13 23:08, Krzysztof Konopko wrote:
> The reason for that is that the system has a
> requirement to assign UIDs and GIDs dynamically without modifying
> /etc/passwd & friends.  The other reason is that the libc implementation
> we are constrained to (certain version of uClibc) doesn't support
> alternative methods of user authentication (e. g. NSS [1]) nor D-Bus
> supports PAM authentication.

To be honest this sounds like it would be better done with a patched
libc, or if you can't do that, linking a "my_getpwent[_r]()" with
libdbus and applying the minimal patch to make it use that instead. That
would also be applicable to every other application that uses

(See also Android's Bionic libc, whose getpwent is hard-coded to map a
certain UID/GID range to synthesized users of the form 'app%d', if I
remember correctly.)

Rummaging in /proc for credentials is an interesting approach: if done
incorrectly it can be a time of check/time of use vulnerability, but I
think you've avoided that.

The potential vulnerability is if you delay credentials lookups until
messages are sent/received (which mainstream libdbus carefully doesn't
do, but third-party LSM integration has sometimes done), a process can
avoid the checks by becoming more privileged while keeping the same pid,
by exec()ing a setuid binary. Exploit: send a message that you shouldn't
be allowed to send, then immediately exec() a binary that *would* have
been allowed to send it. You are now racing with the dbus-daemon. If
dbus-daemon wins the race, the exploit doesn't work, but if you win the
race, by the time it asks your credentials you've been replaced by a
more privileged binary, and the message is wrongly accepted


More information about the dbus mailing list