Cách giải quyết 'Không có giao thức được chỉ định' cho người dùng su


15

Tôi đang cố gắng sử dụng một người dùng thay thế (không phải quản trị viên) để thực thi phần mềm đồ họa trên hệ thống của tôi. Người dùng thay thế này đã được đặt tên và cung cấp UID và GID để khớp với người dùng hệ thống từ xa cùng tên. UID là 500 vì vậy tôi tin rằng điều đó làm cho người dùng trở thành người dùng 'không đăng nhập'.

Bắt đầu từ Ubuntu đăng nhập vào tài khoản chính của tôi, tôi mở một thiết bị đầu cuối và sucho người dùng thay thế. Sau đó tôi cố gắng thực thi lệnh để khởi động ứng dụng và nhận được 'Không có giao thức được chỉ định'.

Đây có phải là do UID <1000, vì suhay vì không phải quản trị viên của người dùng? Làm cách nào tôi có thể khiến người dùng này thực thi ứng dụng bằng GUI?

Câu trả lời:


15

Vấn đề không xảy ra do UID của người dùng. 500 cũng tốt như một UID và UID đó không biến nó thành người dùng 'không đăng nhập' ngoại trừ trong mắt các cài đặt mặc định của một vài trình quản lý hiển thị.

Thông báo lỗi Không có giao thức nào được chỉ định nghe giống như thông báo lỗi dành riêng cho ứng dụng và thông báo lỗi không hữu ích ở đó, nhưng tôi đoán rằng lỗi là ứng dụng không thể liên lạc với màn hình X11 của bạn vì nó không được phép thực hiện vì nó chạy như một người dùng khác Các ứng dụng cần có "cookie ma thuật" (mã thông báo bí mật) để nói chuyện với máy chủ X11 để các quy trình khác trên hệ thống chạy dưới người dùng khác không thể xâm nhập vào màn hình của bạn, tạo cửa sổ và rình mò gõ phím. Người dùng hệ thống khác không có quyền truy cập vào cookie ma thuật này vì các quyền được đặt sao cho người dùng bắt đầu môi trường máy tính để bàn chỉ có thể truy cập được (đúng như vậy).

Hãy thử điều này, chạy với tư cách là người dùng ban đầu của bạn, để sao chép cookie X11 sang tài khoản khác:

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

sau đó chạy ứng dụng của bạn Bạn cũng có thể cần phải bỏ đặt XAUTHORITYtrong vỏ đó. Lệnh đó trích xuất cookie ma thuật ( xauth list) từ người dùng chính của bạn và thêm nó ( xauth add) vào nơi người dùng khác có thể lấy nó.


Thật kỳ lạ, sử dụng lệnh được trích dẫn của bạn sẽ cho 'su: phải được chạy từ một thiết bị đầu cuối'. Nhưng nó một thiết bị đầu cuối ...
J Collins

@JCollins thử xauth list >/tmp/xa.$$; su - <otheruser> -c "unset XAUTHORITY; xargs xauth add </tmp/xa.$$"; rm -f /tmp/xa.$$nhưng hãy lưu ý rằng có một điều kiện cuộc đua khủng khiếp ở đó.
roaima

@JCollins oops, yeah, đó sẽ là một vấn đề nếu sumuốn hỏi mật khẩu. Hãy thử lệnh mới này.
Celada

@Celada, vàng, làm việc một điều trị. Bạn có thể đi vào chi tiết lệnh đó đang làm gì và làm thế nào không? Và có thể giải thích tại sao hóa thân ban đầu không?
J Collins

1
@JCollins bạn sẽ phải làm lại mỗi lần sau khi bạn đăng xuất và đăng nhập vì một cookie ma thuật hoàn toàn mới được tạo ra mỗi lần. Điều đó là bình thường, đó là một phần của mô hình bảo mật.
Celada

6

Tôi trường hợp của tôi máy chủ hiển thị mới wayland là vấn đề,

cứ làm đi xhost + local: sau đó những người dùng khác (ví dụ root) được phép chạy Chương trình trong phiên của bạn, tuy nhiên kết nối mạng sẽ không được phép.

Nếu bạn muốn cho phép khách hàng từ bất kỳ máy chủ nào , bạn có thể sử dụng xhost +mà không chỉ định bất kỳ máy chủ nào. Tuy nhiên , điều này không an toàn , sẽ tốt hơn nếu chỉ định (các) máy chủ mà bạn muốn cấp quyền truy cập vào phiên của mình.


1
Trong trường hợp của tôi xhost +là đủ đủ
nguy hiểm89

1
@ risk89 trong khi điều này không hoạt động, nó cho phép bất kỳ máy chủ nào kết nối với phiên của bạn nếu bạn không có quy tắc tường lửa để ngăn truy cập từ xa (Không phải mọi phân phối đều có quy tắc tường lửa từ chối tất cả các yêu cầu đến, ví dụ như ubfox không có các quy tắc được cấu hình sẵn để ngăn truy cập vào máy chủ như samba hoặc apache mà người dùng có thể muốn cài đặt) vì vậy đối với người dùng linux mới, điều này có thể trở thành một vấn đề. Cá nhân tôi sẽ giới hạn quyền truy cập chỉ ở phía lưu
MADforFUNandHappy

3

Giả sử bạn muốn vũ phu hãy tạo cho mình một kết nối với X ...

Giả sử bạn đã chạy các lệnh của mình trên máy chủ (nơi X chạy), nếu không, hãy để nó hoạt động trước và sau đó sử dụng 'ssh -X user @ server) từ máy khách sau đó;).

Có thể có một số cách để chạy các lệnh xauth, ví dụ, bạn có thể đang sử dụng 'sudo', nhưng điều đó có thể làm mất hoặc thay đổi các biến môi trường. Các biến môi trường sau đây cần được bảo tồn: HIỂN THỊ và XAUTHORITY. Để kiểm tra xem đó có phải là trường hợp bạn có thể chạy 'echo $ XAUTHORITY' giống như cách bạn chạy các lệnh của mình không, nhưng hãy đảm bảo rằng bạn không mở rộng các biến môi trường trước khi chạy các lệnh đó. Ví dụ: thử: sudo bash -c 'echo "$ XAUTHORITY"' để xem XAUTHORITY thực sự là gì sau khi bạn chạy sudo của mình (nếu nó biến mất, bạn có thể cần thêm một cái gì đó vào tệp sudoers của mình, xem ở nơi khác).

Cuối cùng, hãy chạy lệnh sau với tư cách là người dùng mà bạn muốn có quyền truy cập trên máy chủ:

xauth info

Điều này sẽ hiển thị 'tệp quyền' sẽ được sử dụng (/root/.Xmasterity theo mặc định, cho root hoặc một cái gì đó như /home/theuser/.Xmasterity). Nếu nó hiển thị tệp .Xmasterity chính xác thì bạn không phải lo lắng về biến môi trường XAUTHORITY thực sự (thực ra, tôi sẽ không biết khi nào nó sẽ không, trừ khi bạn muốn thao tác một vị trí không chuẩn của tệp đó ).

Xóa tệp đó (nếu nó còn tồn tại):

rm /root/.Xauthority

Thay thế /root/.Xauthority bằng tệp XAUTHORITY chính xác cho trường hợp của bạn.

Tạo lại nó, nhưng trống rỗng (điều này là cần thiết cho rất nhiều lệnh):

touch /root/.Xauthority

Tại thời điểm này, bạn sẽ nhận được lỗi Không có giao thức được chỉ định , ngay cả khi bạn đã nhận MIT-MAGIC-COOKIE-1 không hợp lệ trước đó. Tìm tệp quyền mà máy chủ X đang sử dụng tại thời điểm này:

ps aux | grep Xorg

Điều này sẽ hiển thị một cái gì đó như:

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

Tên tệp sau -authlà những gì bạn cần trong lệnh tiếp theo. Chạy cái này với quyền root:

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

Nó liệt kê một khóa thập lục phân 32 chữ số. Ví dụ: đầu ra có thể là:

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

Sử dụng điều đó để tạo tệp .Xmasterity của bạn (với tư cách là người dùng cần đăng nhập lại):

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

thay thế 'c0eaf749aa252101a0f57d5087089db7' bằng lệnh danh sách trả về cho bạn. Bây giờ .Xmasterity của bạn phải có kích thước 51 byte và bạn có thể kết nối với máy chủ X (một lần nữa).


Không có chủ đề, đây là trang web Hỏi & Đáp, không phải diễn đàn
Anthon

2

Hãy thử một cái gì đó như thế

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

nguồn

Ps : câu trả lời được chấp nhận không hiệu quả với tôi


1

Tôi đã gặp lỗi này "Không có giao thức được chỉ định" khi tôi khởi động phiên bản Selenium 3.3.1 từ tập lệnh khởi động và sau đó sử dụng trình điều khiển Chrome trong Selenium. Selenium chạy cùng một người dùng với X11 và biến môi trường vỏ HIỂN THỊ được đặt chính xác. Điều thú vị là lỗi này đã không xảy ra khi tôi sử dụng trình điều khiển Firefox. Đặt biến môi trường vỏ XAUTHORITY bên trong tập lệnh khởi động để trỏ đến giá trị $ XAUTHORITY của người dùng X11 đang hoạt động đã sửa lỗi cho trình điều khiển Chrome.

Mặt khác, lỗi "Không có giao thức được chỉ định" đã bị trình điều khiển Chrome / Chrome chôn vùi triệt để và không dễ tìm thấy. Tôi nhận thấy rằng Chrome tiếp tục tạo các thư mục theo mẫu /tmp/.org.chromium.Chromium.*, nhưng chúng đã nhanh chóng biến mất. Tôi quản lý để ý rằng họ chứa một tập tin chrome_debug.logcó thông báo "Không thể hiển thị mở". Tôi nhận ra điều này khá kỳ lạ vì tôi đã xác minh rằng quy trình Selen có HIỂN THỊ chính xác /proc/$pid/environvà kiểm tra đầu ra của stracequy trình Selenium kỹ lưỡng hơn, điều này cho thấy "Không có giao thức nào được chỉ định" cuối cùng dẫn đến câu hỏi này.

Lỗi này có thể được sao chép bằng cách bỏ đặt XAUTHORITY và cố gắng chạy một số máy khách X11. Ví dụ:

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

0

Điều này thật đơn giản. Vấn đề xảy ra khi bạn ở root sate và muốn sử dụng gksu Chỉ cần thoát khỏi trạng thái root và thử lại


0

Chỉ cần nhập cái này vào terminal của bạn xhost +SI:localuser:rootsau đó bạn gõ export DISPLAY=:0.0rồi thử lại


0

Sử dụng manh mối trong các câu trả lời được chấp nhận, tôi có thể giải quyết vấn đề theo cách khác:

  1. Xác định vị trí tệp Xauth trong tài khoản hoạt động (Xauth1)
  2. Xác định vị trí tệp Xauth trong tài khoản không (Xauth2)
  3. Sao chép Xauth1 sang Xauth2
  4. Thay đổi quyền của Xauth2

Trong mã:

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

Giả sử bạn cố gắng truy cập GUI dưới dạng user2 ( người dùng bình thường ), sau đó Bạn cần tải UI cài đặt với tên user2 .

Hãy thử làm theo điều này:

Đăng nhập bằng root :

sudo su

Kiểm tra máy chủ x:

xclock

Nếu bạn có thể thấy đồng hồ đang chạy, thật tuyệt, hãy thử chạy cái này:

xhost

Kết quả sẽ như thế này:

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

Bây giờ hãy để user2 truy cập xhost

xhost +SI:localuser:user2

Bây giờ hãy thử đăng nhập lại vào user2 và thử mở bất kỳ chương trình GUI nào.

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.