Mengapa saya mendapatkan "layar berakhir" tanpa root?

Saya telah menginstal layar pada Fedora 19. Ketika saya menguji perintah sebagai root dari jarak jauh melalui SSH, ia bekerja dengan sempurna. Sebagai contoh, jika saya memasuki screenterminal emulator baru dimulai dan menunggu perintah. Saya dapat melepaskannya, dll. Namun ketika saya mencoba melakukan hal yang sama setelah saya login dari jarak jauh melalui SSH sebagai pengguna standar, perintah berakhir segera. Satu-satunya pesan yang saya lihat adalah [screen is terminating].

Apakah seseorang sudah memiliki masalah ini? Apakah ini terkait dengan izin yang buruk?

Memperbarui:

$ 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 +++

Saya telah mencoba mengubah izin menjadi 777 tetapi kemudian ketika saya mengeksekusi screen, saya mendapatkan:

Direktori '/ var / run / layar' harus memiliki mode 775.

Karenanya, saya telah mengembalikan perubahan saya.

Flip-flopping antara "must have mode 777" dan "must have mode 775" disebabkan oleh strace.

screenbiasanya program setuid atau setgid. Ini mendapatkan hak istimewa tambahan ketika dieksekusi, yang digunakan untuk membuat file socket dan / atau memodifikasi utmp.

Ketika suatu proses sedang dilacak, setuid dan setgid dinonaktifkan. Proses penelusuran, dikendalikan oleh pengguna yang kurang beruntung, dapat mengambil alih proses yang dilacak sehingga harus berjalan tanpa hak istimewa tambahan untuk menghindari memberikan kekuatan terlalu banyak kepada pengguna asli.

screen mendeteksi apakah sedang dijalankan dengan hak akses setuid, hak setgid, atau tidak, dan menyesuaikan harapannya terhadap izin direktori yang sesuai.

Jadi ini menciptakan kelas masalah yang tidak dapat dengan mudah dibantah strace.

Tetapi jika Anda root, ada solusinya! Jika proses penelusuran berjalan sebagai root, maka proses yang dilacak dapat memperoleh hak istimewa secara normal. Jadi, inilah yang Anda lakukan:

1. Buka 2 terminal baru
2. Di terminal pertama, masuk ke mesin jarak jauh sebagai root
3. Di terminal kedua, masuk ke mesin jarak jauh seperti pengguna normal
4. Gunakan psuntuk mendapatkan PID dari proses shell pengguna normal di terminal kedua
5. Di terminal pertama, jalankan strace -f -p SHELLPID
6. Di terminal kedua, jalankan layar dan lihat gagal
7. Di terminal pertama, Anda sekarang memiliki strace log yang Anda butuhkan untuk mencari tahu apa yang sebenarnya salah.

Tambahan kunci pada straceperintah adalah -fopsi, yang memerintahkannya untuk melacak proses anak. Anda membutuhkannya untuk melacak layar yang akan menjadi anak dari proses shell yang Anda tentukan -p.

Saya juga suka menggunakan -ffdan menentukan file output dengan -o, seperti pada

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

yang akan membuat file output terpisah untuk setiap proses anak. Setelah itu Anda membacanyaless /tmp/screentrace* dan hasilnya biasanya lebih bersih daripada apa yang Anda dapatkan menggunakan satu -f.

MEMPERBARUI

Sekarang saya telah melihat output strace, saya tidak tahu persis apa yang salah, tetapi baris ini adalah hal yang paling mengejutkan dalam penelusuran:

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

Beberapa baris sebelumnya, itu menciptakan pty, yang dinyatakan oleh TIOCGPTNmenjadi nomor 2.

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

Tapi itu tidak bisa dikunyah. Saya tidak tahu mengapa gaun itu akan gagal, tetapi kegagalan gaun itu memberikan alasan yang masuk akal mengapa layar menyerah. Anda bisa mendapatkan sedikit informasi lebih lanjut dengan menambahkan -vopsi strace, dan melihat statsetelah TIOCGPTNuntuk melihat siapa yang memiliki /dev/pts/entri.

Salah satu alasan yang mungkin untuk bug itu - kebijakan selinux yang salah, tetapi menurut redhat bugtracker kesalahan tersebut diperbaiki di fedora 17/18.

Sebagai solusinya, Anda dapat mengubah variabel SCREENDIRdi dalam diri Anda ~/.bashrcmenjadi sesuatu seperti $HOME/.screen.

Ketika saya menemukan pesan kesalahan ini. Saya harus menyesuaikan izin saya dengan yang berikut:

chmod 2775 /usr/bin/screen

Dan ini menyelesaikan masalah bagi saya. 2 sangat penting untuk izin akses yang benar.

Anda harus membaca lebih lanjut tentang SUID, SGID, Sticky Bit, ACL, dan bagaimana pengaruhnya terhadap akses.

Perintah layar sudah berjalan. Jadi saya menghentikannya dan mengetik ulang perintah. Ya ini bukan resolusi yang cukup bagus seperti yang lain tetapi butuh waktu lebih sedikit untuk melakukan ini.

Hanya ps dan temukan pid, bunuh PID dan lanjutkan dengan mengetik ulang perintah layar lagi.

Jika Anda menjalankan beberapa perintah layar, pastikan Anda menghentikan proses yang benar terkait dengan terminal Anda.

Saya menemukan masalah ini teratasi setelah mengomentari baris berikut di / etc / fstab dan me-reboot:

devpts         /dev/pts        devpts  defaults        0       0

Pastikan tidak ada orang lain screenyang menggunakan perangkat itu

Ini dapat dicapai dengan /superuser/97844/how-can-i-determine-what-process-has-a-file-open-in-linux :

sudo lsof /dev/ttyS0

Dan kemudian bunuh proses itu jika itu masalahnya.

Untuk beberapa alasan, dalam kondisi ini, sudo screenmasih dapat mengakses perangkat, tetapi kemudian koneksi itu akan kehilangan karakter, yang dikonsumsi oleh yang lain screen.

Pastikan pengguna telah membaca dan menulis izin untuk file tersebut

Misalnya di Ubuntu Anda ingin menambahkan pengguna ke dialoutgrup: /ubuntu//a/133244/52975

Saya mendapatkan masalah yang persis sama dan keluaran strace yang sangat mirip.

Ini memperbaikinya:

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

kredit: https://www.linuxquestions.org/questions/linux-newbie-8/screen-terminates-immediately-4175444530/