Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#825153: nslcd: Numerous '<passwd="*"> request denied by validnames option' log entries
1,252 views
Skip to first unread message
Daniel Richard G.
May 24, 2016, 4:00:03 AM5/24/16
to
Package: nslcd
Version: 0.9.6-3
Severity: minor
I am seeing relatively frequent entries of this form in syslog:
May 24 03:04:23 darkstar nslcd[1187]: [3c9869] <passwd="*"> request denied by validnames option
While I am uncertain as to what causes this, at one point it appeared to
be associated with tab completion at a shell prompt. (At the same time,
however, I can't reproduce this reliably that way.)
I claim ignorance as to why this request occurs (is this really supposed
to return a list of all users?) and it is probably not nslcd that is
responsible for it in the first place. But given that this request comes
up fairly often, and does not appear to be the result of a
misconfiguration, it would be helpful to have a way of keeping this
noise out of the log. The "*" request could be specifically ignored,
while continuing to log other instances of failed validnames matching.
(Incidentally, "nss_disable_enumeration yes" does not address this.)
Version: 0.9.6-3
Severity: minor
I am seeing relatively frequent entries of this form in syslog:
May 24 03:04:23 darkstar nslcd[1187]: [3c9869] <passwd="*"> request denied by validnames option
While I am uncertain as to what causes this, at one point it appeared to
be associated with tab completion at a shell prompt. (At the same time,
however, I can't reproduce this reliably that way.)
I claim ignorance as to why this request occurs (is this really supposed
to return a list of all users?) and it is probably not nslcd that is
responsible for it in the first place. But given that this request comes
up fairly often, and does not appear to be the result of a
misconfiguration, it would be helpful to have a way of keeping this
noise out of the log. The "*" request could be specifically ignored,
while continuing to log other instances of failed validnames matching.
(Incidentally, "nss_disable_enumeration yes" does not address this.)
Arthur de Jong
May 24, 2016, 3:00:03 PM5/24/16
to
On Tue, 2016-05-24 at 03:27 -0400, Daniel Richard G. wrote:
> I am seeing relatively frequent entries of this form in syslog:
>
> May 24 03:04:23 darkstar nslcd[1187]: [3c9869] request denied by validnames option
> I am seeing relatively frequent entries of this form in syslog:
>
>
> While I am uncertain as to what causes this, at one point it appeared
> to be associated with tab completion at a shell prompt. (At the same
> time, however, I can't reproduce this reliably that way.)
I'm not really sure what triggers it but I also see this in the logs a
> While I am uncertain as to what causes this, at one point it appeared
> to be associated with tab completion at a shell prompt. (At the same
> time, however, I can't reproduce this reliably that way.)
lot. I just ignore it. It could be that nscd makes it more difficult to
trigger because it sometimes also caches negative hits. Furthermore,
the application may be caching it.
> I claim ignorance as to why this request occurs (is this really
> supposed to return a list of all users?)
nu users at all or a misconfiguration somewhere.
> But given that this request comes up fairly often, and does not
> appear to be the result of a misconfiguration, it would be helpful to
> have a way of keeping this noise out of the log. The "*" request
> could be specifically ignored, while continuing to log other
> instances of failed validnames matching.
/^[a-z0-9._@$()*]([a-z0-9._@$() \\~-]*[a-z0-9._@$()~-])?$/i
but that is a bit ugly and it results in a useless LDAP search each
time.
> (Incidentally, "nss_disable_enumeration yes" does not address this.)
function call can also return only one passwd entry so it is not meant
to be a wildcard. As such it is not covered by nss_disable_enumeration.
Not sure this will be fixed in nss-pam-ldapd any time soon.
Thanks,
--
-- arthur - ade...@debian.org - http://people.debian.org/~adejong --
Daniel Richard G.
May 24, 2016, 4:30:03 PM5/24/16
to
On Tue, 2016 May 24 20:47+0200, Arthur de Jong wrote:
>
> I'm not really sure what triggers it but I also see this in the logs a
> lot. I just ignore it. It could be that nscd makes it more difficult
> to trigger because it sometimes also caches negative hits.
> Furthermore, the application may be caching it.
Ah, yes, that makes sense. I'm using nscd as well.
>
> I'm not really sure what triggers it but I also see this in the logs a
> lot. I just ignore it. It could be that nscd makes it more difficult
> to trigger because it sometimes also caches negative hits.
> Furthermore, the application may be caching it.
> > I claim ignorance as to why this request occurs (is this really
> > supposed to return a list of all users?)
>
> No, I'm pretty sure it is some sort of lookup that is meant to return
> nu users at all or a misconfiguration somewhere.
considered a bug?
(I'd be happy to file a report, as long as the maintainer is not likely
to respond with "working as designed, closing.")
> To not report it as an invalid name you could set validnames to
>
> /^[a-z0-9._@$()*]([a-z0-9._@$() \\~-]*[a-z0-9._@$()~-])?$/i
>
> but that is a bit ugly and it results in a useless LDAP search
> each time.
you're talking about many clients).
Arthur de Jong
May 24, 2016, 4:50:06 PM5/24/16
to
On Tue, 2016-05-24 at 16:24 -0400, Daniel Richard G. wrote:
> > No, I'm pretty sure it is some sort of lookup that is meant to
> > return nu users at all or a misconfiguration somewhere.
>
> If I can find what is doing this, should the behavior be
> considered a bug?
At the very least it is weird behaviour. I don't expect any NSS module
> > No, I'm pretty sure it is some sort of lookup that is meant to
> > return nu users at all or a misconfiguration somewhere.
>
> If I can find what is doing this, should the behavior be
> considered a bug?
would return useful information. It could be a compat lookup thing but
I thought it only worked on "+" entries, not "*" and those entries are
only supported in flat files (/etc/passwd, /etc/shadow).
If you could track it down I would be very interested to know why some
application would do that. If this is some kind of standard use of the
API I'm not aware of perhaps that would be an argument to change the
behaviour of nslcd.
Running nslcd in debug mode will show application pids that perform the
request, that will probably help in tracking it down.
Daniel Richard G.
May 24, 2016, 7:10:02 PM5/24/16
to
On Tue, 2016 May 24 22:42+0200, Arthur de Jong wrote:
>
> At the very least it is weird behaviour. I don't expect any NSS module
> would return useful information. It could be a compat lookup thing but
> I thought it only worked on "+" entries, not "*" and those entries are
> only supported in flat files (/etc/passwd, /etc/shadow).
>
> If you could track it down I would be very interested to know why some
> application would do that. If this is some kind of standard use of the
> API I'm not aware of perhaps that would be an argument to change the
> behaviour of nslcd.
>
> Running nslcd in debug mode will show application pids that perform
> the request, that will probably help in tracking it down.
Ah, yes, that is very helpful. I have some information for you.
>
> At the very least it is weird behaviour. I don't expect any NSS module
> would return useful information. It could be a compat lookup thing but
> I thought it only worked on "+" entries, not "*" and those entries are
> only supported in flat files (/etc/passwd, /etc/shadow).
>
> If you could track it down I would be very interested to know why some
> application would do that. If this is some kind of standard use of the
> API I'm not aware of perhaps that would be an argument to change the
> behaviour of nslcd.
>
> Running nslcd in debug mode will show application pids that perform
> the request, that will probably help in tracking it down.
The culprit here is Bash, although what specifically within Bash is
harder to suss out. The issue does appear to be in the bash_completion
logic, because if I disable that, the "*" requests go away.
The completion logic is about as close to line noise as typical Perl, so
I can't make much headway in there. But strace shows a connect() call to
the nslcd socket for each request, and no other connect()s, so I ran a
debug build of bash in a debugger.
After picking through the backtrace, I've found exactly what is
generating the request. Below, I've copied the entire shell function in
question (from /usr/share/bash-completion/bash_completion), and have
marked the offending line:
# This function quotes the argument in a way so that readline dequoting
# results in the original argument. This is necessary for at least
# `compgen' which requires its arguments quoted/escaped:
#
# $ ls "a'b/"
# c
# $ compgen -f "a'b/" # Wrong, doesn't return output
# $ compgen -f "a\'b/" # Good
# a\'b/c
#
# See also:
# - http://lists.gnu.org/archive/html/bug-bash/2009-03/msg00155.html
# - http://www.mail-archive.com/bash-compl...@lists.alioth.\
# debian.org/msg01944.html
# @param $1 Argument to quote
# @param $2 Name of variable to return result to
_quote_readline_by_ref()
{
if [ -z "$1" ]; then
# avoid quoting if empty
printf -v $2 %s "$1"
elif [[ $1 == \'* ]]; then
# Leave out first character
printf -v $2 %s "${1:1}"
elif [[ $1 == ~* ]]; then <---------------- HERE
# avoid escaping first ~
printf -v $2 ~%q "${1:1}"
else
printf -v $2 %q "$1"
fi
# Replace double escaping ( \\ ) by single ( \ )
# This happens always when argument is already escaped at cmdline,
# and passed to this function as e.g.: file\ with\ spaces
[[ ${!2} == *\\* ]] && printf -v $2 %s "${1//\\\\/\\}"
# If result becomes quoted like this: $'string', re-evaluate in order to
# drop the additional quoting. See also: http://www.mail-archive.com/
# bash-compl...@lists.alioth.debian.org/msg01942.html
[[ ${!2} == \$* ]] && eval $2=${!2}
} # _quote_readline_by_ref()
There are other instances of "~*" in the file, but they all have a
backslash escaping the tilde.
Would you agree that this appears to be a bug in bash-completion?
Arthur de Jong
May 25, 2016, 5:00:03 PM5/25/16
to
On Tue, 2016-05-24 at 19:01 -0400, Daniel Richard G. wrote:
> After picking through the backtrace, I've found exactly what is
> generating the request. Below, I've copied the entire shell function
> in question (from /usr/share/bash-completion/bash_completion), and
> have marked the offending line:
[...]
> After picking through the backtrace, I've found exactly what is
> generating the request. Below, I've copied the entire shell function
> in question (from /usr/share/bash-completion/bash_completion), and
> have marked the offending line:
> There are other instances of "~*" in the file, but they all have a
> backslash escaping the tilde.
Good find. Thanks for tracking this down!
> backslash escaping the tilde.
> > Would you agree that this appears to be a bug in bash-completion?
Daniel Richard G.
May 25, 2016, 6:50:04 PM5/25/16
to
On Wed, 2016 May 25 22:54+0200, Arthur de Jong wrote:
>
> Good find. Thanks for tracking this down!
Getting the PID of the requesting process was the piece I was missing :)
>
> Good find. Thanks for tracking this down!
> > > Would you agree that this appears to be a bug in bash-completion?
>
> I would think so. Please file a bug against bash-completion.
Cursory testing after a manual fix shows no more "*" queries. That gets
rid of the need to mitigate the resulting log entries, so unless
something else starts making bad queries and can't be fixed, this bug
report may be closed. Thank you for your help!
0 new messages