ルートなしで「画面が終了しています」と表示されるのはなぜですか？

Fedora 19に画面をインストールしました。SSHを介してrootとしてコマンドをリモートでテストすると、完全に機能します。たとえばscreen、新しい端末を入力すると、エミュレータが起動し、コマンドを待ちます。デタッチできます。しかし、SSHを介して標準ユーザーとしてリモートでログインすると、同じことをしようとすると、コマンドはすぐに終了します。私が見る唯一のメッセージはです[screen is terminating]。

誰かがすでにこの問題を抱えていますか？不正なアクセス許可に関連していますか？

更新：

$ strace -e trace=file screen
execve("/usr/bin/screen", ["screen"], [/* 23 vars */]) = 0
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libutempter.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libpam.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libfreebl3.so", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libaudit.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
access("/home/steam/.nethackrc", F_OK)  = -1 ENOENT (No such file or directory)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
lstat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
open("/var/run/utmp", O_RDONLY)         = 3
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
open("/etc/shadow", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
stat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
lstat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
stat("/var/run/screen", {st_mode=S_IFDIR|0775, st_size=60, ...}) = 0
Directory '/var/run/screen' must have mode 777.
+++ exited with 1 +++

私は許可を777に変更しようとしましたが、実行するscreenと次のようになります：

ディレクトリ「/ var / run / screen」にはモード775が必要です。

したがって、変更を元に戻しました。

「must have mode 777」と「must have mode 775」の間のフリップフロップは、によって引き起こされstraceます。

screen通常、setuidまたはsetgidプログラムです。実行時に追加の特権を取得します。これは、ソケットファイルの作成やutmpの変更に使用されます。

プロセスのトレース中は、setuidとsetgidは無効になります。特権の低いユーザーによって制御されるトレースプロセスは、トレースされたプロセスを引き継ぐことができるため、元のユーザーに過剰なパワーを与えないように、余分な特権なしで実行する必要があります。

screen setuid特権、setgid特権、またはどちらでも実行されているかどうかを検出し、それに応じてディレクトリのアクセス許可に対する期待を調整します。

そのため、これを使用すると簡単にデバッグできない問題のクラスが作成されstraceます。

ただし、rootの場合は、回避策があります！トレースプロセスがルートとして実行されている場合、トレースされたプロセスは通常の権限を取得できます。そのため、次のことを行います。

1. 2つの新しいターミナルを開く
2. 最初の端末で、rootとしてリモートマシンにログインします
3. 2番目のターミナルで、通常のユーザーとしてリモートマシンにログインします。
4. ps2番目の端末で通常のユーザーのシェルプロセスのPIDを取得するために使用します
5. 最初のターミナルで、実行します strace -f -p SHELLPID
6. 2番目のターミナルで画面を実行し、失敗するのを見てください
7. 最初のターミナルでは、実際に何が問題なのかを見つけるために必要なstraceログがあります。

straceコマンドへの重要な追加は、-f子プロセスをトレースするように指示するオプションです。で指定したシェルプロセスの子になる画面をトレースするために必要です-p。

私も使用したい-ffとして、出力ファイルを指定-oのように、

strace -ff -o /tmp/screentrace -p SHELLPID

子プロセスごとに個別の出力ファイルが作成されます。その後、あなたはそれらを読んless /tmp/screentrace*で、結果は通常あなたがシングルを使って得たものよりもきれいです-f。

更新

straceの出力を見たので、何が間違っていたのか正確にはわかりませんが、この行はトレースで最も驚くべきものです。

chown("/dev/pts/2", 1002, 5)            = -1 EPERM (Operation not permitted)

数行前に、ptyが作成されましたTIOCGPTN。

open("/dev/ptmx", O_RDWR)               = 5
...
ioctl(5, TIOCGPTN, [2])                 = 0
stat("/dev/pts/2", {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0

しかし、それをかじることはできませんでした。私はそのchownが失敗する理由を知りませんが、chownの失敗はスクリーンがscreenめたもっともらしい理由を与えます。-vstraceオプションに追加し、エントリの所有者を確認statするTIOCGPTNために後を見て、もう少し情報を取得できます/dev/pts/。

そのバグの考えられる理由-間違ったselinuxポリシーですが、redhatバグトラッカーによると、そのようなエラーはfedora 17/18で修正されました。

回避策として、変数をのようなものに変更できSCREENDIRます。~/.bashrc$HOME/.screen

このエラーメッセージが表示されたとき。次のように許可を調整する必要がありました。

chmod 2775 /usr/bin/screen

そして、これで問題は解決しました。2は正しいアクセス許可のために非常に重要です。

SUID、SGID、スティッキービット、ACL、およびそれらがアクセスに与える影響について詳しく読む必要があります。

画面コマンドはすでに実行されていました。そこで、それを終了し、コマンドを再入力しました。はい、これは他の人のようなかなり良い解像度ではありませんが、これを行うのに時間がかかりません。

psでpidを見つけ、PIDを強制終了してから、画面コマンドの再入力を続行します。

複数の画面コマンドを実行している場合は、端末に関連付けられている正しいプロセスを必ず終了してください。

/ etc / fstabの次の行にコメントを付けて再起動すると、この問題が解決したことがわかりました。

devpts         /dev/pts        devpts  defaults        0       0

他の人screenがそのデバイスを使用していないことを確認してください

これは/superuser/97844/how-can-i-determine-what-process-has-a-file-open-in-linuxで実現できます：

sudo lsof /dev/ttyS0

そして、その場合はそのプロセスを強制終了します。

何らかの理由で、この条件下でsudo screenは、デバイスにアクセスできますが、その接続では、他のデバイスによって消費される文字が失われscreenます。

ユーザーにファイルの読み取りおよび書き込み権限があることを確認します

たとえば、ユーザーをdialoutグループに追加するUbuntuの場合：https : //askubuntu.com/a/133244/52975

私はまったく同じ問題とかなり似たstrace出力を得ました。

これにより修正されました。

sudo chmod u+s /usr/bin/screen
sudo chmod 755 /var/run/screen

クレジット：https : //www.linuxquestions.org/questions/linux-newbie-8/screen-terminates-immediately-4175444530/