Neden root olmadan "ekran sonlandırılıyor" alıyorum?


23

Fedora 19'a ekran yükledim. Komutu SSH üzerinden uzaktan root olarak test ettiğimde mükemmel çalışıyor. Mesela screenyeni bir terminal emülatörü girersem başlatılır ve komutları bekler. Bunu çıkarabilirim, vb. Ancak aynı şeyi yapmaya çalıştığımda, standart bir kullanıcı olarak SSH üzerinden uzaktan oturum açtığımda, komut derhal sonlandırılıyor. Gördüğüm tek mesaj [screen is terminating].

Birisi zaten bu sorunu yaşadı mı? Kötü izinlerle mi ilgili?

Güncelleştirme:

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

İzinleri 777 olarak değiştirmeye çalıştım, ancak çalıştırdığımda şunu screenalıyorum:

'/ Var / run / screen' dizini 775 moduna sahip olmalıdır.

Bu nedenle değişikliklerimi geri aldım.


Komut nedir?
ewwhite

En basit olanı: "ekran". Ben de bir örnek kaydedilen shelr.tv/records/525179c7966080791000005f

Tesadüfen bir VPS veya barındırılan sunucuda mısınız?
ewwhite

Bu barındırılan bir sunucudur

strace -e trace=file screenDosya erişiminde başarısız olup olmadığını kontrol etmek için. Ya tmuxda bir geçici çözüm olarak kullanır , eserleri ^ a yerine ^ b kullanması dışında çalışır.
Emmanuel,

Yanıtlar:


5

"777 modu olmalı" ve "775 modu olmalı" arasındaki çeviriden kaynaklanıyor strace.

screengenellikle bir setuid veya setgid programıdır. Soket dosyaları oluşturmak ve / veya utmp değiştirmek için kullanılan, yürütüldüğünde fazladan ayrıcalıklar kazanır.

Bir işlem izlendiğinde setuid ve setgid devre dışı bırakılır. Daha az ayrıcalıklı kullanıcı tarafından kontrol edilen izleme süreci, asıl kullanıcıya çok fazla güç vermekten kaçınmak için fazladan ayrıcalıklara sahip olmadan çalışması gereken izlenen işlemi devralabilir.

screen setuid ayrıcalıklarıyla mı, setgid ayrıcalıklarıyla mı yoksa hiçbiriyle mi çalıştırıldığını algılar ve dizin izinlerinin beklentisini buna göre ayarlar.

Bu da kolayca hata ayıklanamayan bir sorun sınıfı yaratır strace.

Ancak, kök iseniz, bir geçici çözüm var! İzleme işlemi kök olarak çalışıyorsa, izlenen işlem normal olarak ayrıcalıklar kazanabilir. İşte burada yaptığınız şey:

  1. 2 yeni terminal aç
  2. İlk terminalde, uzak makineye root olarak giriş yapın.
  3. İkinci terminalde, uzaktaki makineye normal kullanıcı olarak giriş yapın.
  4. psİkinci terminalde normal kullanıcının kabuk işleminin PID değerini almak için kullanın
  5. İlk terminalde koş strace -f -p SHELLPID
  6. İkinci terminalde, ekranı çalıştırın ve başarısız izlemek
  7. İlk terminalde, şimdi neyin yanlış olduğunu bulmak için ihtiyacınız olan strace kütüğüne sahipsiniz.

straceKomuta anahtar ekleme -f, alt süreçleri izlemesini söyleyen seçenektir. Belirlediğiniz kabuk işleminin alt öğesi olacak ekranı izlemeniz gerekir -p.

Ayrıca -ffbir çıktı dosyasını olduğu gibi kullanmak ve belirtmek istiyorum -o.

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

bu her alt süreç için ayrı bir çıktı dosyası oluşturacaktır. Daha sonra bunları okudunuz less /tmp/screentrace*ve sonuç genellikle tek kullandığınızdan daha temiz -f.

GÜNCELLEŞTİRME

Şimdi strace çıktısını gördüm, neyin yanlış gittiğini tam olarak bilmiyorum, ama bu çizgi izlemedeki en şaşırtıcı şey:

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

Birkaç satır önce, TIOCGPTN2 numara olduğu ortaya çıkan bir çukur yarattı .

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

Ama onu boğmadı. O chown'un neden başarısız olacağını bilmiyorum ama chown başarısızlığı ekranın neden pes etmesi konusunda makul bir sebep veriyor. Sen ekleyerek biraz daha fazla bilgi alabilirsiniz -vstrace seçeneklerine ve bakarak statsonra TIOCGPTNkime ait olduğunu görmek için /dev/pts/girdiyi.


Detaylı prosedür için teşekkür ederim. Strace tarafından üretilen çıktıya bakmaya çalıştım ama yanlış olanı bulamıyorum. Bundan sonra strace tarafından oluşturulan üç dosyanın içeriğine sahip link bulunur: pastebin.com/raw.php?i=aeqDwTBX herhangi bir fikir memnuniyetle karşılanır :)
Laurent

2

Bu hatanın olası nedenleri üzerine - yanlış selinux politikaları, ancak redhat bugtracker'a göre bu tür hatalar 17/18 federasyonunda giderildi.

Çözüm olarak, değişkenleri SCREENDIRsizin ~/.bashrcgibi bir şeyle değiştirebilirsiniz $HOME/.screen.


Denedim ama bu sorunu çözmüyor.
Laurent,

1

Bu hata mesajıyla karşılaştığımda. İzinlerimi aşağıdaki şekilde ayarlamak zorunda kaldım:

chmod 2775 /usr/bin/screen

Ve bu benim için sorunu çözdü. Doğru erişim izinleri için 2 çok önemlidir.

SUID, SGID, Yapışkan Bit, ACL'ler ve erişimi nasıl etkiledikleri hakkında daha fazla bilgi edinmelisiniz.


çalışıyor. Güzel değil ama şu anda başka çözümler göremiyorum.
Antti Rytsölä

0

Ekran komutu zaten çalışıyordu. Bu yüzden onu sonlandırdım ve komutu tekrar yazdım. Evet, bu diğerleri gibi oldukça iyi bir çözünürlük değil, ancak bunu yapmak için daha az zaman alıyor.

Sadece ps ve pid bulmak, PID öldürmek ve yeniden ekran komutunu yeniden yazarak devam edin.

Birden fazla ekran komutu kullanıyorsanız, terminalinizle ilişkili doğru işlemi sonlandırdığınızdan emin olun.


0

/ Etc / fstab içindeki şu satırı yorumladıktan ve yeniden başlattıktan sonra bu sorunu çözdüm:

devpts         /dev/pts        devpts  defaults        0       0

0

screenBu cihazı başka kimsenin kullanmadığından emin olun

Bu /superuser/97844/how-can-i-determine-what-process-has-a-file-open-in-linux ile elde edilebilir :

sudo lsof /dev/ttyS0

Ve eğer öyleyse, bu süreci öldürün.

Bazı nedenlerden dolayı, bu koşul altında sudo screen, cihaza hala erişebilir, ancak o zaman bu bağlantı diğer tarafından tüketilen karakterleri özleyecektir screen.

Kullanıcının dosyaya okuma ve yazma izni verdiğinden emin olun

Örn: Ubuntu'da kullanıcıyı dialoutgruba eklemek istiyorsunuz : /ubuntu//a/133244/52975


Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.