polkit fails to authenticate on dbus
karu.pruun
karu.pruun at gmail.com
Wed Jan 21 06:08:45 PST 2015
On Tue, Jan 20, 2015 at 10:58 PM, Thiago Macieira wrote:
> On Tuesday 20 January 2015 22:41:44 karu.pruun wrote:
>> On Tue, Jan 20, 2015 at 10:07 PM, Thiago Macieira <thiago at kde.org> wrote:
>> > On Tuesday 20 January 2015 20:48:52 karu.pruun wrote:
>> >> Can anyone tell me what does the argument ('30' in the FreeBSD case
>> >> and '34323934393637323935' in the DragonFly) in the EXTERNAL
>> >> authentication protocol of dbus stand for?
>> >
>> > It's the hex encoding of the UID, in decimal
>> >
>> > 30 = "0" =
>> > root
>> > 34323934393637323935 = "4294967295" = probably "nobody"
>> >
>> > Are you connecting to the system bus?
>>
>> Thanks. Yes connecting to the system bus but failing. I wonder where
>> in the polkitd code that UID string '34323934393637323935' is
>> computed? I wonder if the error is with polkitd computing the wrong
>> UID.
>
> Probably from getuid() returning that. You tell me whether it's possible for
> the syscall to return UINT_MAX on Dragonfly -- on Linux, it isn't, since
> ULONG_MAX-4095..ULONG_MAX are reserved for error codes.
>
> The system daemon will allow any UID to be passed there, provided it exists in
> /etc/passwd.
This is weird, I have no UID '4294967295' (the hex encoding you give
above) in /etc/passwd, user 'nobody' has UID '65534'.
I ran a few tests with kernel trace (ktrace) and got strange results
on DragonFly: long story short, getuid() returns the correct UID for
polkitd (0 for root and 1001 for a test user), but the UID string used
by polkitd for 'AUTH EXTERNAL . . .' a little later is always that
same string '34323934393637323935'. In other words, there is no
correlation between what getuid() returns and will be used by polkitd
a little later for authentication; polkitd always authenticates with
AUTH EXTERNAL 34323934393637323935
I ran the same test on FreeBSD, where it works fine: the UID returned
by getuid() will be used a little later for authentication in 'AUTH
EXTERNAL . . .'.
This seems to narrow down the problem a little bit.
Peeter
--
More information about the dbus
mailing list