Backport #6831
closedtest_getpwuid() on Mountain Lion
Description
When using Mountain Lion, following test failure occur.
- Failure:
test_getpwuid(TestEtc) [/ruby/git/test/etc/test_etc.rb:34]:
<#<struct Struct::Passwd
name="_appleevents",
passwd="",
uid=55,
gid=55,
gecos="AppleEvents Daemon",
dir="/var/empty",
shell="/usr/bin/false",
change=0,
uclass="",
expire=0>> expected but was
<#<struct Struct::Passwd
name="_pcastagent",
passwd="",
uid=55,
gid=55,
gecos="Podcast Producer Agent",
dir="/var/pcast/agent",
shell="/usr/bin/false",
change=0,
uclass="",
expire=0>>.
getpwent() of Mountain Lion seems buggy. see below:
test_getpwent.c¶
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <pwd.h>
int main(void)
{
struct passwd *ent;
while((ent = getpwent()) != NULL) {
if (ent->pw_uid == 55)
printf("%s:%d:%s\n", ent->pw_name, ent->pw_uid, ent->pw_gecos);
}
return 0;
}
result¶
_appleevents:55:AppleEvents Daemon
_pcastagent:55:Podcast Producer Agent
mrkn, what do you think?
Updated by kosaki (Motohiro KOSAKI) about 12 years ago
Is this right way to skip?
diff --git a/test/etc/test_etc.rb b/test/etc/test_etc.rb
index c4db71c..dafcdbb 100644
--- a/test/etc/test_etc.rb
+++ b/test/etc/test_etc.rb
@@ -29,7 +29,15 @@ class TestEtc < Test::Unit::TestCase
def test_getpwuid
passwd = {}
- Etc.passwd {|s| passwd[s.uid] ||= s }
- Etc.passwd {|s|
-
# skip if passwd database has duplicated entry
-
# especially getpwent(3) on Mac OS X often return duplicated entry by default.
-
if passwd.has_key?(s.uid)
-
return
-
end
-
passwd[s.uid] ||= s\
-
passwd.each_value do |s|}
assert_equal(s, Etc.getpwuid(s.uid))
assert_equal(s, Etc.getpwuid) if Process.euid == s.uid
Updated by nobu (Nobuyoshi Nakada) about 12 years ago
It doesn't seem duplicated, but just two entries sharing same uid.
I think it is a bug of the test, which does not consider such case, so don't agree your patch.
Updated by nobu (Nobuyoshi Nakada) about 12 years ago
- Status changed from Assigned to Feedback
=begin
Does this patch fix it?
diff --git i/test/etc/test_etc.rb w/test/etc/test_etc.rb
index c4db71c..b73a95f 100644
--- i/test/etc/test_etc.rb
+++ w/test/etc/test_etc.rb
@@ -29,9 +29,16 @@ class TestEtc < Test::Unit::TestCase
def test_getpwuid
- passwd = {}
- Etc.passwd {|s| passwd[s.uid] ||= s }
- passwd.each_value do |s|
-
assert_equal(s, Etc.getpwuid(s.uid))
-
assert_equal(s, Etc.getpwuid) if Process.euid == s.uid
-
password database is not unique on UID, and which entry will be¶
-
returned by getpwuid() is not specified.¶
- passwd = Hash.new {[]}
-
on MacOSX, same entries are returned from /etc/passwd and Open¶
-
Directory.¶
- Etc.passwd {|s| passwd[s.uid] |= [s]}
- passwd.each_pair do |uid, s|
-
assert_include(s, Etc.getpwuid(uid))
- end
- s = passwd[Process.euid]
- if s
-
endassert_include(s, Etc.getpwuid)
end
=end
Updated by kosaki (Motohiro KOSAKI) about 12 years ago
- Status changed from Feedback to Assigned
- Assignee changed from mrkn (Kenta Murata) to nobu (Nobuyoshi Nakada)
Does this patch fix it?
Yes.
Updated by nobu (Nobuyoshi Nakada) about 12 years ago
- Status changed from Assigned to Closed
- % Done changed from 0 to 100
This issue was solved with changeset r36625.
Motohiro, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.
test_etc.rb: remove implicit assumption
- test/etc/test_etc.rb (TestEtc#test_getpwuid): remove implicit
assumption, that getpwuid() would return the first entry in the
order of getpw(), for shared UID. apparently it is not true on
MacOS X 10.8. [ruby-core:46975][Bug #6831]
Updated by reeze (reeze xia) about 12 years ago
Hi,
I got a question about Etc.getpwnam && Etc.getgrnam in Mac OS X, Both of them will return a found entry for empty string "".
Since they are related to Etc. so I posted here.
1.9.3p125 :007 > Etc.getpwnam("")
=> #<struct Struct::Passwd name="", passwd="", uid=0, gid=0, gecos="", dir="", shell="", change=0, uclass="", expire=0>
1.9.3p125 :008 > Etc.getgrnam("")
=> #<struct Struct::Group name="", passwd="", gid=0, mem=[]>
This didn't happen in other OS, Does OSX have an empty user and group ?
PS: I didn't find any empty username and empty grounpname in etc files.
Thanks
Updated by kosaki (Motohiro KOSAKI) about 12 years ago
This didn't happen in other OS, Does OSX have an empty user and group ?
Only Apple can answer this. we can't. Etc extension is just wrapper functionality of OS feature.
So, I suggest you report it to apple.
thanks.
Updated by nobu (Nobuyoshi Nakada) about 12 years ago
FYI, it raises ArgumentError which means "a matching entry is not found", on Lion.
Updated by nobu (Nobuyoshi Nakada) about 12 years ago
=begin
BTW, I found the following statement in getpwnam(3) on Lion.
The functions getpwnam() and getpwuid() search the password database for the given login name or user uid, respectively, always returning the first one encountered.
This definitely states which entry should be returned when multiple logins are sharing the same UID.
Has this changed on Mountain Lion?
=end
Updated by reeze (reeze xia) about 12 years ago
Hi nobu,
The man page about getpwnam didn't changed a lot, just a new function was added.
The functions getpwnam(), getpwuid(), and getpwuuid() search the password database for the given
login name, user uid, or user uuid respectively, always returning the first one encountered.
Note that the password file /etc/master.passwd does not contain user UUIDs. The UUID for a user
may be found using mbr_uid_to_uuid().
Thanks
Updated by reeze (reeze xia) about 12 years ago
kosaki (Motohiro KOSAKI) wrote:
This didn't happen in other OS, Does OSX have an empty user and group ?
Only Apple can answer this. we can't. Etc extension is just wrapper functionality of OS feature.
So, I suggest you report it to apple.
Thanks kosaki, I will try to report it apple.
thank:)
thanks.
Updated by nobu (Nobuyoshi Nakada) about 12 years ago
reeze (reeze xia) wrote:
The man page about getpwnam didn't changed a lot, just a new function was added.
Thank you.
It obviously differs from the result in your original post.
You may want to report it to Apple.
Certainly getpwname() on MacOS X 10.8 seems buggy, still I think the test should be kept as the recent, since other platforms (e.g., Linux) don't state the result in such case.
Updated by nobu (Nobuyoshi Nakada) about 12 years ago
- Tracker changed from Bug to Backport
- Project changed from Ruby master to Backport193
- Category deleted (
ext) - Status changed from Closed to Assigned
- Assignee changed from nobu (Nobuyoshi Nakada) to usa (Usaku NAKAMURA)
- Target version deleted (
2.0.0)
Updated by usa (Usaku NAKAMURA) about 12 years ago
- Status changed from Assigned to Closed
This issue was solved with changeset r37210.
Motohiro, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.
merge revision(s) 36625: [Backport #6831]
test_etc.rb: remove implicit assumption
* test/etc/test_etc.rb (TestEtc#test_getpwuid): remove implicit
assumption, that getpwuid() would return the first entry in the
order of getpw(), for shared UID. apparently it is not true on
MacOS X 10.8. [ruby-core:46975][Bug #6831]