You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@apr.apache.org by bu...@apache.org on 2015/08/20 16:58:07 UTC

[Bug 58264] New: APR 1.5.3 test fails with "apr_gid_compare failed ... passwords do not match"

https://bz.apache.org/bugzilla/show_bug.cgi?id=58264

            Bug ID: 58264
           Summary: APR 1.5.3 test fails with "apr_gid_compare failed ...
                    passwords do not match"
           Product: APR
           Version: 1.5.3
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: blocker
          Priority: P2
         Component: APR
          Assignee: bugs@apr.apache.org
          Reporter: apache@clacke.user.lysator.liu.se

When compiling APR 1.5.3 I get the following test output:

testuser            :  Line 73: apr_gid_compare failed (70024): passwords do
not match

I am doing this on a SLES 11.3 machine, but I'm doing it inside the guix
package manager, running as unprivileged with --disable-chroot, so I have a
pretty exotic context for this error. I will try running it as a manual build
too, to see if the results are different.

But I'm reading the APR source code, specifically user/unix/groupinfo.c, and I
cannot find where the string "passwords do not match" would even come from.
Doesn't the code finally boil down to (left == right)?

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org


[Bug 58264] APR 1.5.3 test fails with "apr_gid_compare failed ... passwords do not match"

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=58264

Rainer Jung <ra...@kippdata.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #3 from Rainer Jung <ra...@kippdata.de> ---
Closing as WONTFIX due to somewhat exotic test conditions.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org


[Bug 58264] APR 1.5.3 test fails with "apr_gid_compare failed ... passwords do not match"

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=58264

--- Comment #2 from Claes Wallin (韋嘉誠) <ap...@clacke.user.lysator.liu.se> ---
Oh!

Yes, I was running it under newgrp for reasons.

I think this is something normal to do and probably shouldn't trigger an error
in tests, but now at least I know enough to be able to work around it. Thanks
for the analysis!

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org


[Bug 58264] APR 1.5.3 test fails with "apr_gid_compare failed ... passwords do not match"

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=58264

--- Comment #1 from Rainer Jung <ra...@kippdata.de> ---
"passwords do not match" comes from misc/unix/errorcodes.c. In
apr_error_string():

    case APR_EMISMATCH:
        return "passwords do not match";

and then in include/apr_user.h:

#define apr_gid_compare(left,right) (((left) == (right)) ? APR_SUCCESS :
APR_EMISMATCH)

The test fails in test/testuser.c line 73:

 32 static void username(abts_case *tc, void *data)
 33 {
 34     apr_uid_t uid;
 35     apr_gid_t gid;
 36     apr_uid_t retreived_uid;
 37     apr_gid_t retreived_gid;
 38     char *uname = NULL;
 39
 40     APR_ASSERT_SUCCESS(tc, "apr_uid_current failed",
 41                        apr_uid_current(&uid, &gid, p));
 42
 43     APR_ASSERT_SUCCESS(tc, "apr_uid_name_get failed",
 44                        apr_uid_name_get(&uname, uid, p));
...
 49
 50     APR_ASSERT_SUCCESS(tc, "apr_uid_get failed",
 51                        apr_uid_get(&retreived_uid, &retreived_gid, uname,
p));
 52
...
 72         APR_ASSERT_SUCCESS(tc, "apr_gid_compare failed",
 73                            apr_gid_compare(gid, retreived_gid));
...
 77 }

So the name associated with the current uid returns another primary guid, then
the one for used the current process. You might add some debug output to see
the actual values.

Regards,

Rainer

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org