Date: Mon, 25 Aug 2003 22:25:24 -0400 From: Eric van Gyzen <vangyzen@stat.duke.edu> To: freebsd-current@freebsd.org Subject: Hesiod grplist Implementation Message-ID: <200308252225.24017.vangyzen@stat.duke.edu>
next in thread | raw e-mail | index | archive | help
I plan to implement support for the "grplist" Hesiod Type, and would like some advice and/or sanity checks. It seems that the best way is to modify getgrouplist() and make it little more than a call to nsdispatch(), similar to getgrent_r(). I would write backend methods such as files_grplist, dns_grplist, etc. to be called from nsdispatch. My *_grplist methods would need to iterate over their respective databases, essentially calling getgrent but without going through nsswitch. The obvious way to do this without duplicating a lot of code is to call the corresponding methods from getgrent.c, such as files_group. The problem is, they are static methods, and not visible from getgrouplist.c. Could they be [renamed and] exported? Could getgrouplist() be moved into getgrent.c? How else could this problem be solved? Should the group-%d "compatibility" be retained as a fallback in the absence of a grplist RR for the given user? Are there any sites out there using Hesiod /without/ grplist RRs? There is no real need to remove it, but... Using all configured services to find group memberships seems most logical. Otherwise, where would I stop? Stopping on a "first match" doesn't make sense. Opinions? Thanks in advance, Eric -- Eric van Gyzen Sr. Systems Programmer http://www.stat.duke.edu/~vangyzen/ ISDS, Duke University
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200308252225.24017.vangyzen>