-----Original Message----- From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] Sent: Tuesday, June 02, 2009 2:13 AM To: John Kane Cc: openldap-technical@openldap.org Subject: Re: 'unary operator expected' error when TLS turned on - SOLVED
I note it may not be easy with the software you are using, but this thread would probably be easier to read for everyone if you refrained from top- posting.
[JK]
Thanks for you rely. All of my comments are 'in-line'.
Personally, I prefer any response to my mails be posted at the top where I can read it initially, especially when threads get extremely long. To each his own, I guess. :-)
On Tuesday 02 June 2009 07:02:04 John Kane wrote:
This is worse than I thought.
Quoting myself:
fix your configuration issue which prevents users from looking up their own user details (such as numerical
uid),
which is sure to break some applications.
[JK]
If my user cannot see his own numerical ID, why does this work (issued from the user in question):
$ /usr/bin/id -u 1805
and why would this only be an issue when TLS is on, and not when TLS is off?
No commands executed from the bash start scripts are returning a value. And, even simple command line
commands,
when a sub-shell is required, return nothing. For instance, when
TLS
is
turned on, these commands return results:
cat /etc/hosts grep local /etc/hosts /usr/bin/id -u echo xxx
But the following return nothing:
cat /etc/hosts | grep local echo `/usr/bin/id -u`
In fact, I don't even see the second set of commands hit LDAP
(running
slapd in debug mode).
They won't, since nss_ldap will refuse to connect to the server if it can't decide if the server has a valid certificate or not.
[JK]
I am confused...why is the user allowed to authenticate and login, issue commands (that return results), but just not commands that require a secondary sub-shell?
$ grep local /etc/hosts 127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
$ /usr/bin/id -u 1805 $ echo xxx xxx $ $ cat /etc/hosts | grep local $ $ echo xxx = `/usr/bin/id -u` xxx = $
BUT, when I turn off TLS (set 'ssl off' in /etc/ldap.conf)
$ cat /etc/hosts | grep local 127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
$ echo xxx = `/usr/bin/id -u` xxx = 1805 $
Any ideas why the sub-shell would not go to LDAP?
Yes. Those were stated in my previous reply. Most likely, your CA certificate is not readable by the user in question, which means it can't do certificate validation, which means it will refuse to connect to the LDAP server, which means any user information lookups performed as the user will fail, which will cause many applications to not work.
Please, consider investigating as I recommended in my previous mail.
E.g., as the user in question, how about:
cat /etc/openldap/cacerts/cacert.pem
If that doesn't return the certificate, you need to correct the permissions so it does, or instead use a configuration where the user doesn't load nss_ldap ... such as using nscd.
[JK]
Sorry, but permissions was one of the first things I investigated. The following is done logged in as 'the user in question':
$ ll /etc/openldap/cacerts/cacert.pem -rw-rw-r-- 1 root root 3305 May 28 04:45 /etc/openldap/cacerts/cacert.pem $ cat /etc/openldap/cacerts/cacert.pem Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: sha1WithRSAEncryption etc., etc.
Also, once again, commands that do not invoke a secondary sub-shell work, I see them hit LDAP.
I am confused with your statement about not loading nss_ldap. Are there known problems with this?
Thanks, John
-----Original Message----- From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] Sent: Monday, June 01, 2009 8:21 AM To: openldap-technical@openldap.org Cc: John Kane Subject: Re: 'unary operator expected' error when TLS turned on - SOLVED
On Sunday 31 May 2009 16:24:49 John Kane wrote:
Adding the 'set -x' option top of /etc/profile, I was able to
determine
the culprit of the
"-bash: [: =: unary operator expected"
error that has been occurring on all Linux servers since turning
on
LDAP
TLS on INT.
In the file:
/etc/profile.d/krb5-workstation.sh
The follow is causing the issue:
if ! echo ${PATH} | /bin/grep -q /usr/kerberos/sbin ; then if [ `/usr/bin/id -u` = 0 ] ; then PATH=/usr/kerberos/sbin:${PATH} fi fi
If I add " " around the backticked command, I the bash error
goes
away.
Not sure who I need to open a ticket against :-)
Depends if you want the bug to be fixed (which, while satisfying,
will
still leave you with real problems), or fix your configuration issue
which
prevents users from looking up their own user details (such as numerical
uid),
which is sure to break some applications.
You should probably investigate why the output 'id -u' is empty,
most
likely it is permissions on the certificate.
'ls -l /etc/openldap/cacerts/cacert.pem'
If that's not it, you need to look further.
You can probably track it down with 'strace -e open id -u', or similar.
This message is confidential to Prodea Systems, Inc unless otherwise indicated or apparent from its nature. This message is directed to the intended recipient only, who may be readily determined by the sender of this message and its contents. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient:(a)any dissemination or copying of this message is strictly prohibited; and(b)immediately notify the sender by return message and destroy any copies of this message in any form(electronic, paper or otherwise) that you have.The delivery of this message and its information is neither intended to be nor constitutes a disclosure or waiver of any trade secrets, intellectual property, attorney work product, or attorney-client communications. The authority of the individual sending this message to legally bind Prodea Systems is neither apparent nor implied,and must be independently verified.