On Mon, Jan 25, 2010 at 04:03:38PM -0700, Dave Serls wrote: > On Mon, 25 Jan 2010 21:47:38 +0100 > Aurelien Jarno <aurel...@aurel32.net> wrote: > > > On Mon, Jan 25, 2010 at 01:14:28PM -0700, Dave Serls wrote: > > > On Mon, 25 Jan 2010 21:06:49 +0100 > > > Aurelien Jarno <aurel...@aurel32.net> wrote: > > > > > > > On Mon, Jan 25, 2010 at 11:38:13AM -0700, Dave Serls wrote: > > > > > On Mon, 25 Jan 2010 18:23:03 +0100 > > > > > Aurelien Jarno <aurel...@aurel32.net> wrote: > > > > > > > > > > > Dave Serls a écrit : > > > > > > > Generates many messages of the form: > > > > > > > ypserv[1349]: refused connect from 192.168.1.1:35691 to procedure > > > > > > > ypproc_match > > > > > > > (dashs.denver.co.us,passwd.adjunct.byname;-1) > > > > > > > > > > > > I guess it is on the server right? This mesages is there, as it > > > > > > refuses > > > > > > to serve a passwd.adjunct.byname to a non-priviledged user (coming > > > > > > from > > > > > > a port >= 1024). > > > > > > > > > > Yes, the ypserv on the old Mandrake system gives the error. > > > > > > > > > > > > > which appear to be provoked by some NSS call from 'wget'. > > > > > > > This was never the case with previous libnss_nis.so > > > > > > > > > > > > > > I've narrowed down the source of the NIS ypmatch call to a > > > > > > > invocation of the getpwuid() primitive in perl 5.10.0. > > > > > > > > > > > > > > > > > > > That's strange, because with the patch to fix the NIS shadow leak, > > > > > > passwd.adjunct.byname calls have been removed for normal calls, and > > > > > > are > > > > > > now only done when querying shadow entries. > > > > > > > > > > > > Have you tried to reproduce the bug by running a simple C code > > > > > > calling > > > > > > getpwuid()? > > > > > > > > > > OK, I'll try that now. A straight call to getpwuid does not > > > > > generate the error. So it must be something extra that perl 5.10 > > > > > is > > > > > doing in its call. > > > > > > > > > > > > Also, can you please share the contents of your /etc/nsswitch.conf? > > > > > > > > > > it is attached. > > > > > > > > > > I might add that there are no regular user entries in the local > > > > > passwd/shadow files > > > > > for the work station, so NIS must be used. > > > > > > > > > > I changed the code in the perl script "GrabWeather" to not use the > > > > > "getwpuid" primitive > > > > > and almost all the 'ypmatch ' errors have stopped. There is one > > > > > that occurs out of the morning > > > > > anacron of cron.daily that I can't locate yet. > > > > > > > > > > > > > Thanks for the info, I have been able to reproduce the problem here. > > > > Can you please confirm that even before you get this same kind of lines > > > > with "shadow.byname" instead (at least with the default ypserv config)? > > > > > > I'm not clear on your intent. > > > Are you saying that the yp server should previously (old libc6) have > > > been emitting errors indicating > > > "shadow.byname" instead of "passwd.adjunct.byname"? > > > > In my tests, it previously output: > > > > Jan 25 19:46:24 nis ypserv[2531]: refused connect from 10.243.120.26:57469 > > to procedure ypproc_match (aurel32,shadow.byname;-1) > > > > Now it outputs: > > Jan 25 19:55:12 nis ypserv[2531]: refused connect from 10.243.120.26:35205 > > to procedure ypproc_match (aurel32,shadow.byname;-1) > > Jan 25 19:55:12 nis ypserv[2531]: refused connect from 10.243.120.26:40967 > > to procedure ypproc_match (aurel32,passwd.adjunct.byname;-1) > > > > In other words two lines instead of one. Does it matches what you see? > > It may actually depends on what you have in /etc/ypserv.conf. > > Prior to the libc6 update, I received no messages of that type in the > syslog of the yp server. > > After the update I began receiving pairs like: > Jan 23 08:14:00 dashs ypserv[1349]: refused connect from 192.168.1.1:33472 > to procedure ypproc_match (dashs.denver.co.us,passwd.adjunct.byname;-1) > Jan 23 08:14:00 dashs ypserv[1349]: refused connect from 192.168.1.1:50897 > to procedure > ypproc_match (dashs.denver.co.us,passwd.adjunct.byname;-1) >
Can you please share your /etc/ypserv.conf on the server? With the default configuration, I also see those messages, but in addition to the shadow.byname messages. In the default configuration file, they have the same access right. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org