Tại sao tôi nhận được màn hình trên mạng chấm dứt mà không có root?


23

Tôi đã cài đặt màn hình trên Fedora 19. Khi tôi kiểm tra lệnh dưới quyền root từ xa thông qua SSH, nó hoạt động hoàn hảo. Chẳng hạn, nếu tôi nhập screenmột trình giả lập thiết bị đầu cuối mới được khởi động và chờ lệnh. Tôi có thể tách nó ra, v.v. Tuy nhiên, khi tôi cố gắng thực hiện tương tự khi tôi đăng nhập từ xa thông qua SSH với tư cách là người dùng chuẩn, lệnh sẽ chấm dứt ngay lập tức. Thông điệp duy nhất tôi thấy là [screen is terminating].

Có ai đó đã có vấn đề này? Có liên quan đến quyền xấu?

Cập nhật:

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

Tôi đã cố gắng thay đổi quyền thành 777 nhưng sau đó khi tôi thực thi screen, tôi nhận được:

Thư mục '/ var / run / screen' phải có chế độ 775.

Do đó, tôi đã hoàn nguyên các thay đổi của mình.


Lệnh là gì?
ewwhite

Đơn giản nhất: "màn hình". Tôi đã ghi lại một ví dụ tại Shelr.tv/records/525179c7966080791000005f

Bạn đang ở trên VPS hoặc máy chủ được lưu trữ, tình cờ?
ewwhite

Nó là một máy chủ được lưu trữ

strace -e trace=file screenđể kiểm tra nếu nó không truy cập tập tin. Hoặc sử dụng tmuxnhư một công việc xung quanh, nó hoạt động như nhau ngoại trừ nó sử dụng ^ b thay vì ^ a.
Emmanuel

Câu trả lời:


5

Việc lật giữa "phải có chế độ 777" và "phải có chế độ 775" là do strace.

screenthường là một chương trình setuid hoặc setgid. Nó nhận được các đặc quyền bổ sung khi được thực thi, được sử dụng để tạo các tệp socket và / hoặc sửa đổi utmp.

Khi một quá trình đang được theo dõi, setuid và setgid bị vô hiệu hóa. Quá trình theo dõi, được kiểm soát bởi người dùng ít đặc quyền hơn, có thể tiếp quản quá trình theo dõi để nó phải chạy mà không có đặc quyền bổ sung để tránh cung cấp cho người dùng ban đầu quá nhiều năng lượng.

screen phát hiện xem nó có đang được chạy với các đặc quyền setuid, đặc quyền setgid hay không và điều chỉnh kỳ vọng của nó về các quyền của thư mục cho phù hợp.

Vì vậy, điều này tạo ra một lớp các vấn đề không thể dễ dàng gỡ lỗi strace.

Nhưng nếu bạn đã root, có một cách giải quyết! Nếu quá trình theo dõi đang chạy như root, thì quá trình theo dõi có thể có được đặc quyền bình thường. Vì vậy, đây là những gì bạn làm:

  1. Mở 2 thiết bị đầu cuối mới
  2. Trong thiết bị đầu cuối đầu tiên, đăng nhập vào máy từ xa với quyền root
  3. Trong thiết bị đầu cuối thứ hai, đăng nhập vào máy từ xa như người dùng bình thường
  4. Sử dụng psđể có được PID của quá trình trình bao của người dùng thông thường trong thiết bị đầu cuối thứ hai
  5. Trong thiết bị đầu cuối, chạy strace -f -p SHELLPID
  6. Trong thiết bị đầu cuối thứ hai, chạy màn hình và xem nó thất bại
  7. Trong thiết bị đầu cuối đầu tiên, bây giờ bạn có nhật ký bước bạn cần tìm hiểu điều gì thực sự sai.

Bổ sung quan trọng cho stracelệnh là -ftùy chọn, cho biết nó theo dõi các tiến trình con. Bạn cần nó để theo dõi màn hình sẽ là con của quá trình shell mà bạn đã chỉ định -p.

Tôi cũng thích sử dụng -ffvà chỉ định một tệp đầu ra với -o, như trong

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

sẽ tạo một tệp đầu ra riêng cho mỗi tiến trình con. Sau đó, bạn đọc chúng less /tmp/screentrace*và kết quả thường sạch hơn những gì bạn nhận được khi sử dụng một -f.

CẬP NHẬT

Bây giờ tôi đã thấy đầu ra bước đi, tôi không biết chính xác những gì đã sai, nhưng dòng này là điều đáng ngạc nhiên nhất trong dấu vết:

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

Một vài dòng trước đó, nó đã tạo ra một pty, được tiết lộ TIOCGPTNlà số 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

Nhưng nó đã không thể chown nó. Tôi không biết tại sao chown đó lại thất bại, nhưng thất bại chown không đưa ra lý do chính đáng tại sao màn hình bỏ cuộc. Bạn có thể nhận thêm một chút thông tin bằng cách thêm -vvào các tùy chọn strace và xem xét statsau TIOCGPTNđể xem ai sở hữu /dev/pts/mục nhập.


Cảm ơn bạn đã làm thủ tục chi tiết. Tôi đã cố gắng nhìn vào đầu ra được tạo bởi strace nhưng tôi không thể tìm ra cái gì sai. Sau đây là liên kết với nội dung của ba tệp được tạo bởi strace: pastebin.com/raw.php?i=aeqDwTBX mọi ý tưởng đều được hoan nghênh :)
Laurent

2

Về các lý do có thể cho lỗi đó - chính sách selinux không chính xác, nhưng theo redtracker, lỗi đó đã được sửa trong fedora 17/18.

Như cách giải quyết, bạn có thể thay đổi biến SCREENDIRtrong bạn ~/.bashrcthành một cái gì đó như $HOME/.screen.


Tôi đã thử nhưng nó không giải quyết được vấn đề.
Laurent

1

Khi tôi gặp thông báo lỗi này. Tôi đã phải điều chỉnh quyền của mình bằng cách sau:

chmod 2775 /usr/bin/screen

Và điều này đã giải quyết vấn đề cho tôi. 2 là rất quan trọng cho các quyền truy cập chính xác.

Bạn nên đọc thêm về SUID, SGID, Bit dính, ACL và cách chúng ảnh hưởng đến quyền truy cập.


u + s hoạt động. Nó không đẹp nhưng tôi không thể thấy các giải pháp khác vào lúc này.
Vòng tròn Antti Rytsölä Tham khảo

0

Lệnh màn hình đã chạy. Vì vậy, tôi đã chấm dứt nó và gõ lại lệnh. Vâng, đây không phải là một độ phân giải khá tốt như những người khác nhưng nó mất ít thời gian hơn để làm điều này.

Chỉ cần ps và tìm pid, tiêu diệt PID và tiếp tục với việc gõ lại lệnh màn hình.

Nếu bạn đang chạy nhiều lệnh màn hình, hãy đảm bảo bạn chấm dứt đúng quy trình được liên kết với thiết bị đầu cuối của bạn.


0

Tôi thấy vấn đề này được giải quyết sau khi bình luận dòng sau trong / etc / fstab và khởi động lại:

devpts         /dev/pts        devpts  defaults        0       0

0

Đảm bảo không có ai khác screenđang sử dụng thiết bị đó

Điều này có thể đạt được với /superuser/97844/how-can-i-determine-what- process-has-a-file-open-in-linux :

sudo lsof /dev/ttyS0

Và sau đó giết quá trình đó nếu đó là trường hợp.

Vì một số lý do, trong điều kiện này, sudo screenvẫn có thể truy cập thiết bị, nhưng sau đó kết nối đó sẽ bỏ lỡ các ký tự, được sử dụng bởi thiết bị kia screen.

Đảm bảo người dùng đã đọc và ghi quyền vào tệp

Ví dụ: trên Ubuntu bạn muốn thêm người dùng vào dialoutnhóm: https://askubfox.com/a/133244/52975


Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.