Bug#566297: getpwuid -- perl 5.10
On Mon, Jan 25, 2010 at 04:03:38PM -0700, Dave Serls wrote:
> On Mon, 25 Jan 2010 21:47:38 +0100
> Aurelien Jarno <aurelien@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 <aurelien@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 <aurelien@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
aurelien@aurel32.net http://www.aurel32.net
Reply to: