--2oEZHvVXAe659F+M
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sat, Feb 05, 2005 at 01:24:43PM +0100, Antoine Reilles wrote:
  | On Sat, Feb 05, 2005 at 06:17:04PM +1100, Luke Mewburn wrote:
  | > Do the entries returned from "getent passwd" match those at the start
  | > of the the result of "ypcat passwd" ?
  |
  | Oh, yes, you're right, I had'nt noticed that !
  |
  | > If so, is the next entry in the YP passwd map (that getent isn't
  | > returning) correct, or seem corrupt?
  |
  | It looks like a valid entry, however the uid and gid are really big, and
  | this account can't be used, it is an invelid shell :
  | nobody:*:4294967294:4294967294::/rien:/pasdeshell

Those numbers exceed UID_MAX (2147483647) and GID_MAX (2147483647).


  |
  | How can i tell ypcat to ignore that entry ?

You can't, and it's not relevant because the libc passwd parsing
routines don't use ypcat(1) -- they use the yp_first(3)/yp_next(3)
functions.


I've examined the getpwent.c (and getgrent.c) code, and the behaviour
in 2.0 was to skip "dodgy" (un-parseable) entries in getpwent() and
getgrent().
When I overhauled this code recently in -current, I changed the
behaviour to fail the getXXent() lookup when an entry couldn't be
parsed.  This change is causing your problem.

I will look at the getpwent.c (and getgrent.c) code and make it more
robust in the event of "corrupt" entries.

Could you please submit a PR about this problem?


Cheers,
Luke.

--2oEZHvVXAe659F+M
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iD8DBQFCBrdKpBhtmn8zJHIRAkulAKCPUQ/vzj6fsZeu+8SpEqhINA8hjwCbBXO4
Z4M1y43cZEn/gReTzq0a3hU=
=eHfi
-----END PGP SIGNATURE-----

--2oEZHvVXAe659F+M--