web-dev-qa-db-ja.com

suユーザーの「プロトコルが指定されていません」を解決する方法

システムでグラフィカルソフトウェアを実行するために、代替ユーザー(非管理者)を使用しようとしています。この代替ユーザーには名前が付けられ、同じ名前のリモートシステムユーザーと一致するUIDとGIDが与えられています。 UIDは500なので、ユーザーは「非ログイン」ユーザーになると思います。

私のメインアカウントにログインしているUbuntuから始めて、ターミナルを開き、代替ユーザーに対してsuを開きます。次に、コマンドを実行してアプリケーションを起動し、「プロトコルが指定されていません」を受け取ります。

これは、UIDが1000未満か、suが原因か、またはユーザーの非管理者が原因ですか?このユーザーにGUIでアプリケーションを実行させるにはどうすればよいですか?

17
J Collins

問題は、ユーザーのUIDが原因で発生しないです。 500はUIDとしては問題ありませんが、いくつかのディスプレイマネージャーのデフォルト設定を除いて、そのUIDによって「非ログイン」ユーザーになることはありません。

エラーメッセージプロトコルが指定されていませんはアプリケーション固有のエラーメッセージのように聞こえますが、役に立たないメッセージですが、アプリケーションがX11ディスプレイに接続できないため、アプリケーションがX11ディスプレイに接続できないことを推測します。別のユーザーとして実行されているため、アクセス権がありません。 X11サーバーと通信して他のユーザーの下で実行されているシステム上の他のプロセスがディスプレイに侵入したり、ウィンドウを作成したり、キーストロークをスヌープしたりできないようにするには、アプリケーションに「マジックCookie」(シークレットトークン)が必要です。デスクトップシステムを起動したユーザーのみがアクセスできるようにアクセス許可が設定されているため、他のシステムユーザーはこの魔法のCookieにアクセスできません(本来あるべき状態です)。

元のユーザーとして実行して、X11 Cookieを他のアカウントにコピーします。

su - <otheruser> -c "unset XAUTHORITY; xauth add $(xauth list)"

次に、アプリケーションを実行します。そのシェルでもXAUTHORITYの設定を解除する必要がある場合もあります。そのコマンドは、魔法のクッキー(xauth list)をメインユーザーから追加して追加します(xauth add)他のユーザーがそれを取得できる場所に。

15
Celada

私の場合、新しいディスプレイサーバーwaylandが問題でした。

xhost + local:を実行すると、他のユーザー(例:root)がセッションでプログラムを実行できますが、ネットワーク接続は許可されません。

any Hostからのクライアントを許可する場合は、ホストをまったく指定せずにxhost +を使用できます。 ただしこれは安全ではありません、セッションへのアクセスを許可するホストを指定することをお勧めします。

7

力ずくでXとの接続を確立したいとします。

サーバー(Xが実行されている場所)で既にコマンドを実行していると想定します。そうでない場合は、最初にコマンドを実行してから、クライアントから 'ssh -X user @ server)を使用します;)。

Xauthコマンドを実行する方法はいくつかあります。たとえば、 'Sudo'を使用している場合でも、環境変数が失われたり変更されたりする可能性があります。次の環境変数を保持する必要があります:DISPLAYおよびXAUTHORITY。これが当てはまるかどうかをテストするには、コマンドを実行するのと同じ方法で「echo $ XAUTHORITY」を実行できますが、それらのコマンドを実行する前に環境変数を展開していないことを確認してください。たとえば、Sudo bash -c 'echo "$ XAUTHORITY"'を試して、Sudoの実行後に実際にXAUTHORITYが何であるかを確認します(表示されない場合は、sudoersファイルに何かを追加する必要があります。他の場所を参照してください)。

最終的に、サーバー上でアクセスを取得するユーザーとして次のコマンドを実行します。

xauth info

これにより、使用される「権限ファイル」が表示されます(デフォルトでは、/ root/.Xauthority、rootの場合、または/home/theuser/.Xauthorityなど)。正しい.Xauthorityファイルが表示されている場合は、XAUTHORITY環境変数を実際に心配する必要はありません(実際には、そのファイルの非標準の場所を操作したい場合を除いて、いつそうならないかわかりません。 )。

そのファイルを削除します(存在する場合でも)。

rm /root/.Xauthority

/root/.Xauthorityを、ケースに適したXAUTHORITYファイルに置き換えます。

それを再作成しますが、空です(これは多くのコマンドで必要です):

touch /root/.Xauthority

この時点で、以前に無効なMIT-MAGIC-COOKIE-1を取得した場合でも、プロトコルが指定されていませんエラーが表示されます。 Xサーバーが現時点で使用している認証ファイルを見つけます。

ps aux | grep Xorg

これは次のように表示されます。

root 1153 0.0 1.0 149560 44464 tty7 Ss+ dec02 0:00 /usr/lib/xorg/Xorg -nolisten tcp -auth /var/run/sddm/{ef18c483-7891-4e82-80ef-2c8f9bd79711} -background none -noreset -displayfd 17 vt7

-authの後のファイル名は、次のコマンドで必要なものです。これをrootとして実行します。

Sudo xauth -f '/var/run/sddm/{ef18c483-7891-4e82-80ef-2c8f9bd79711}' list

これは、32桁の16進数キーを示しています。たとえば、出力は次のようになります。

hostname/unix:0 MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7

それを使用して.Xauthorityファイルを生成します(再度ログインする必要があるユーザーとして):

xauth add $DISPLAY MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7

「c0eaf749aa252101a0f57d5087089db7」を、listコマンドによって返されたものに置き換えます。これで、.Xauthorityのサイズは51バイトになり、Xサーバーに接続できます(もう一度)。

4
Carlo Wood

そのようなことを試してください

$ export LOGIN_USER="Math"
$ su - $LOGIN_USER
$ Sudo xhost local:$LOGIN_USER &>/dev/null

ソース

Ps:受け入れられた答えは私にとってうまくいきませんでした

3
deFreitas

起動スクリプトからSelenium 3.3.1のインスタンスを起動し、ChromeドライバをSeleniumで使用しました。SeleniumはX11と同じユーザーとして実行されていました。とDISPLAYシェル環境変数が正しく設定されました。興味深いのは、Firefoxドライバーを使用したときにこのエラーが発生しなかったことです。アクティブなX11ユーザーの$ XAUTHORITYの値を指すようにupstartスクリプト内のXAUTHORITYシェル環境変数を設定すると、 Chromeドライバのエラー。

余談ですが、「プロトコルが指定されていません」というエラーはChrome/Chromeドライバーによって完全に埋められており、簡単に見つけることはできませんでした。 Chromeが/tmp/.org.chromium.Chromium.*のパターンでディレクトリを作成し続けているのに気づきましたが、すぐに消えていきました。メッセージのあるファイルchrome_debug.logが含まれていることに気付きました「ディスプレイを開くことができません」。Seleniumプロセスが/proc/$pid/environで正しいDISPLAYを持っていることを確認し、Seleniumプロセスでのstraceの出力をより詳細に調べたため、これはかなり奇妙だと思いました。 「プロトコルが指定されていません」と私は最終的にこの質問に導きました。

このエラーは、XAUTHORITYの設定を解除して、一部のX11クライアントを実行しようとすると再現できます。例えば:

$ XAUTHORITY= xeyes
No protocol specified
Error: Can't open display: :0.0
1
Sasha Pachev

これは簡単でした。この問題は、ルート状態でgksだけを使用したいときに発生しますexitルート状態で再試行します

これをターミナルに入力するだけですxhost +SI:localuser:rootその後、export DISPLAY=:0.0その後、もう一度お試しください

0
kophygiddie

受け入れられた答えの手がかりを使用して、私は問題を別の方法で解決することができました:

  1. 機能するアカウント(Xauth1)でXauthファイルを見つけます。
  2. ないアカウント(Xauth2)でXauthファイルを見つけます。
  3. Xauth1をXauth2にコピーする
  4. Xauth2の権限を変更する

コードで:

root@45c4933a8f1a:~# xauth info
Authority file:       /headless/.Xauthority
<snip>
root@45c4933a8f1a:~# su OtherUser
OtherUser@45c4933a8f1a:/headless$ xauth info
Authority file:       /home/OtherUser/.Xauthority
<snip>
OtherUser@45c4933a8f1a:/headless$ exit
exit
root@45c4933a8f1a:~# cp /headless/.Xauthority /home/OtherUser/.Xauthority 
root@45c4933a8f1a:~# chown OtherUser:OtherUser /home/OtherUser/.Xauthority
root@45c4933a8f1a:~# su OtherUser
0
tjb

ser2normal user))としてGUIにアクセスしようとすると、インストールUIを-としてロードする必要がありますser2

これを試してください:

rootとしてログイン:

Sudo su

Xサーバーをテストします。

xclock

時計が動いているのを確認できたら、それで問題ありません。次を実行してみてください。

xhost

結果は次のようになります。

xhost SI:localuser:tri
# tri is my user name

ser2 xhostにアクセスしましょう

xhost +SI:localuser:user2

ser2に再度ログインして、GUIプログラムのいずれかを開こうとします。

0
Tri