私はLDAP認証環境を稼働させています。LDAPサーバーはUbuntu 12.04マシン上にあり、クライアントはすべてCentos 6.4マシンです。最近、この記事に従ってLDAPでsudoersを設定しました。http://www.malaya-digital.org/configure-ldap-for-sudo-support-in-ubuntu-server-11-04-64-bit/
sudo を使用してコマンドを実行するときに PATH がおかしくなることを除いて、すべて正常に動作します。
sudoのPATHは次のとおりです
# sudo printenv PATH
"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
上記のPATHにリストされているすべてのコマンドは、/binにあるものを除いて実行できるようです。例えば
# sudo which node
/usr/local/bin/node
# sudo which zip
/usr/bin/zip
# sudo which ip
/sbin/ip
# sudo which ls
which: no ls in ("/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin") #WTF??
# sudo ls /
sudo: ls: command not found
ただし、フルパスを使用して /bin でコマンドを実行すると、機能します。
# sudo /bin/ls /
bin boot dev etc home lib lib64 lost+found media mnt NFS opt proc root sbin selinux srv sys tmp usr var
読みましたパス内のsudoの問題そしてLDAP 経由の sudoers のトラブルシューティングしかし、何が問題なのかの手がかりは見つかりません。
PATH 設定を含む LDAP エントリは次のとおりです。
dn: cn=defaults,ou=SUDOers,dc=example.dc=com
objectClass: top
objectClass: sudoRole
cn: defaults
description: Default sudoOption's go here
sudoOrder: 1
sudoOption: env_reset
sudoOption: secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
答え1
私も今日同じ問題に遭遇しましたが、解決策はsecure_pathオプションから二重引用符を削除するだけだと思います。
dn: cn=defaults,ou=SUDOers,dc=example.dc=com
objectClass: top
objectClass: sudoRole
cn: defaults
description: Default sudoOption's go here
sudoOrder: 1
sudoOption: env_reset
sudoOption: secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
を引用符で囲むと、 の結果に見られるようにsudo printenv PATH、PATH自体に引用符が含まれます。これは、ディレクトリ名にコロンが含まれる奇妙な長いパスに対応しているようですが、これは望んでいることではありません...
あなたの回答は、おそらく末尾のコロンが何らかのデフォルト パスを追加するという特別な意味を持つため、問題を回避しているようです。sudo printenv PATH何が起こっているのか確認してみてください --- 私の場合はうまくいきませんでした。
上記で提案した LDIF を使用すると、次のようになりますPATH。
$ sudo printenv PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
答え2
正確な理由はわかりませんが、解決策は自分で見つけました。
非常に簡単です。LDAP エントリの secure_path の末尾に「:」を追加すると、すべての問題が解決します。
secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:"