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
