[Mono-dev] UnixUserInfo issues in OpenBSD
pablosantosluac at terra.es
pablosantosluac at terra.es
Mon Oct 18 05:54:33 EDT 2010
I got the same issue (Mono/C#) running as root.
On 18/10/2010 0:44, Robert Nagy wrote:
> Ignore that diff i just sent, it's stupid, i did not read
> the code correctly. Working on something that fixes the problem
> On (2010-10-18 00:22), Robert Nagy wrote:
>> You get errno 13 (EACCES) because you are not running it as root
>> and getpwnam_r will try to give you struct passwd which inludes
>> the encrypted password of the user so errno will be set to EACCES,
>> but the other fields will be set.
>> According to the comment in mph.h getpnam_r only returns ERANGE on
>> linux and -1 on Mac OS, bt errno == ERANGE was wrong anyways.
>> On OpenBSD we return 1 until everything is okay and then we return 0.
>> The following diff fixes OpenBSD and Mac OS too.
>> diff --git a/support/mph.h b/support/mph.h
>> index 8a61999..08ce5ea 100644
>> --- a/support/mph.h
>> +++ b/support/mph.h
>> @@ -198,8 +198,8 @@ recheck_range (int ret)
>> if (ret == ERANGE)
>> return 1;
>> - if (ret == -1)
>> - return errno == ERANGE;
>> + if (ret != 0)
>> + return errno = ERANGE;
>> return 0;
>> On (2010-10-13 12:56), Jonathan Pryor wrote:
>>> On Wed, 2010-10-13 at 16:38 +0200, pablosantosluac at terra.es wrote:
>>>> This is what I get:
>>>> $ ./a.out tester
>>>> # checking return value 1; errno=13
>>> That's...horribly wrong.
>>> First, what's errno=13? (i.e. what EVALUE is 13? I'm sure OpenBSD has
>>> different values than Linux does.)
>>> Regardless, OpenBSD doesn't appear to be conforming to the standard
>>> If successful, the getpwnam_r() function shall return zero;
>>> otherwise, an error number shall be returned to indicate the
>>> The value '1' is likely not the correct errno for ERANGE (Under Linux,
>>> EPERM has the value 1), and since the return value isn't -1
>>> recheck_range() won't check errno against ERANGE either.
>>> However, this does point out a bug in MonoPosixHelper: if getpwnam_r()
>>> returns non-zero it should treat it as an error, which is clearly not
>>> happening here (and is why we're printing garbage data to the screen).
>>> This would only marginally help you, though, as it would result in no
>>> users being found, ever.
>>> The fundamental problem is that Mono_Posix_Syscall_getpwnam_r()'s logic
>>> for checking for ERANGE (so it'll resize the buffer and try the call
>>> again) is failing under OpenBSD, and from what I can see here the
>>> problem is within OpenBSD, not MonoPosixHelper.
>>> Patches welcome to properly support OpenBSD. :-)
>>> - Jon
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list