Re: [Mono-dev] UnixUserInfo issues in OpenBSD
Hi,
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
correctly.
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, pablosantosl...@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
here:
http://www.opengroup.org/onlinepubs/009695399/functions/getpwnam_r.html
If successful, the getpwnam_r() function shall return zero;
otherwise, an error number shall be returned to indicate the
error.
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@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] UnixUserInfo issues in OpenBSD
Of course you do, that has nothing to do with the issue you
see now.
On (2010-10-18 11:54), pablosantosl...@terra.es wrote:
Hi,
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
correctly.
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, pablosantosl...@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
here:
http://www.opengroup.org/onlinepubs/009695399/functions/getpwnam_r.html
If successful, the getpwnam_r() function shall return zero;
otherwise, an error number shall be returned to indicate the
error.
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@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] UnixUserInfo issues in OpenBSD
I am going to have a look at this. On (2010-10-13 12:56), Jonathan Pryor wrote: On Wed, 2010-10-13 at 16:38 +0200, pablosantosl...@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 here: http://www.opengroup.org/onlinepubs/009695399/functions/getpwnam_r.html If successful, the getpwnam_r() function shall return zero; otherwise, an error number shall be returned to indicate the error. 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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] UnixUserInfo issues in OpenBSD
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, pablosantosl...@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
here:
http://www.opengroup.org/onlinepubs/009695399/functions/getpwnam_r.html
If successful, the getpwnam_r() function shall return zero;
otherwise, an error number shall be returned to indicate the
error.
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@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] UnixUserInfo issues in OpenBSD
Ignore that diff i just sent, it's stupid, i did not read
the code correctly. Working on something that fixes the problem
correctly.
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, pablosantosl...@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
here:
http://www.opengroup.org/onlinepubs/009695399/functions/getpwnam_r.html
If successful, the getpwnam_r() function shall return zero;
otherwise, an error number shall be returned to indicate the
error.
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@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] UnixUserInfo issues in OpenBSD
Hi all,
The following simple program fails on OpenBSD:
using System;
using Mono.Unix;
public class Info
{
public static void Main()
{
Console.WriteLine(Environment.UserName);
Console.WriteLine(new
UnixUserInfo(Environment.UserName).UserName);
Console.WriteLine(UnixUserInfo.GetRealUser().UserName);
}
}
Environment.UserName retrieves the right user.
The two next calls fail saying invalid param:
Console.WriteLine(new UnixUserInfo(Environment.UserName).UserName);
Console.WriteLine(UnixUserInfo.GetRealUser().UserName);
It seems the problem is the return of the native method getpwuid_r, that
returns 1 instead of 0.
I tried running as root to (suspected it could be a permissions issue)
but I get the same result.
I thought it could be related to an old issue with UnixGroupInfo which
fails if the groups are incorrectly defined (have unexisting users) but
I think this time my config files are correctly set... :O
Thanks,
pablo
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] UnixUserInfo issues in OpenBSD
I have no idea why it's failing. Sorry.
What I can do is send you a C program which closely mirrors what
Mono.Unix is doing. Could you compile and run it, and see if it fails
in the same ways? The program source is attached.
- Jon
On Wed, 2010-10-13 at 10:43 +0200, pablosantosl...@terra.es wrote:
Hi all,
The following simple program fails on OpenBSD:
using System;
using Mono.Unix;
public class Info
{
public static void Main()
{
Console.WriteLine(Environment.UserName);
Console.WriteLine(new
UnixUserInfo(Environment.UserName).UserName);
Console.WriteLine(UnixUserInfo.GetRealUser().UserName);
}
}
Environment.UserName retrieves the right user.
The two next calls fail saying invalid param:
Console.WriteLine(new UnixUserInfo(Environment.UserName).UserName);
Console.WriteLine(UnixUserInfo.GetRealUser().UserName);
It seems the problem is the return of the native method getpwuid_r, that
returns 1 instead of 0.
I tried running as root to (suspected it could be a permissions issue)
but I get the same result.
I thought it could be related to an old issue with UnixGroupInfo which
fails if the groups are incorrectly defined (have unexisting users) but
I think this time my config files are correctly set... :O
Thanks,
pablo
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
#include stdio.h
#include stdlib.h
#include sys/types.h
#include pwd.h
#include errno.h
static inline int
recheck_range (int ret)
{
printf (# checking return value %i; errno=%i\n, ret, errno);
if (ret == ERANGE)
return 1;
if (ret == -1)
return errno == ERANGE;
return 0;
}
static void
dump_user (const char *user)
{
int r;
struct passwd p, *prev;
char *buf, *buf2;
size_t buflen;
buf = buf2 = NULL;
buflen = 2;
do {
buf2 = realloc (buf, buflen *= 2);
if (buf2 == NULL) {
printf (error: unable to allocate enough memory\n);
free (buf);
return;
}
buf = buf2;
errno = 0;
} while ((r = getpwnam_r (user, p, buf, buflen, prev)) recheck_range (r));
if (r == 0 !prev) {
printf (User '%s' was not found.\n, user);
free (buf);
return;
}
printf (User %s:\n, user);
printf (\t pw_name=%s\n, p.pw_name);
printf (\t pw_uid=%i\n, p.pw_uid);
printf (\t pw_gid=%i\n, p.pw_gid);
printf (\tpw_gecos=%s\n, p.pw_gecos);
printf (\t pw_dir=%s\n, p.pw_dir);
printf (\tpw_shell=%s\n, p.pw_shell);
free (buf);
}
int main (int argc, char **argv)
{
int i;
for (i = 1; i argc; ++i) {
dump_user (argv [i]);
}
return 0;
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] UnixUserInfo issues in OpenBSD
Reading your C code I see once more how powerful C# is... :P
This is what I get:
$ ./a.out tester
# checking return value 1; errno=13
User tester:
pw_name=ÇEðÄ
À
¢
pw_uid=752427404
pw_gid=-809631572
pw_gecos=(null)
pw_dir=(null)
pw_shell=UåSj
$ ./a.out pablo
# checking return value 1; errno=13
User pablo:
pw_name=ÇEðÄ
À
¢
pw_uid=656871820
pw_gid=-809738964
pw_gecos=(null)
pw_dir=(null)
pw_shell=UåSj
We're getting an errno in both cases...
OpenBSD is a cool beast! :P
On 13/10/2010 15:29, Jonathan Pryor wrote:
I have no idea why it's failing. Sorry.
What I can do is send you a C program which closely mirrors what
Mono.Unix is doing. Could you compile and run it, and see if it fails
in the same ways? The program source is attached.
- Jon
On Wed, 2010-10-13 at 10:43 +0200, pablosantosl...@terra.es wrote:
Hi all,
The following simple program fails on OpenBSD:
using System;
using Mono.Unix;
public class Info
{
public static void Main()
{
Console.WriteLine(Environment.UserName);
Console.WriteLine(new
UnixUserInfo(Environment.UserName).UserName);
Console.WriteLine(UnixUserInfo.GetRealUser().UserName);
}
}
Environment.UserName retrieves the right user.
The two next calls fail saying invalid param:
Console.WriteLine(new UnixUserInfo(Environment.UserName).UserName);
Console.WriteLine(UnixUserInfo.GetRealUser().UserName);
It seems the problem is the return of the native method getpwuid_r, that
returns 1 instead of 0.
I tried running as root to (suspected it could be a permissions issue)
but I get the same result.
I thought it could be related to an old issue with UnixGroupInfo which
fails if the groups are incorrectly defined (have unexisting users) but
I think this time my config files are correctly set... :O
Thanks,
pablo
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] UnixUserInfo issues in OpenBSD
On Wed, 2010-10-13 at 16:38 +0200, pablosantosl...@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 here: http://www.opengroup.org/onlinepubs/009695399/functions/getpwnam_r.html If successful, the getpwnam_r() function shall return zero; otherwise, an error number shall be returned to indicate the error. 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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
