Как решить 'Протокол не указан' для пользователя su

Я пытаюсь использовать альтернативного пользователя (не администратора) для запуска графического программного обеспечения в моей системе. Этот альтернативный пользователь был назван и получил UID и GID для соответствия удаленному системному пользователю с тем же именем. UID равен 500, поэтому я считаю, что это делает пользователя не-авторизованным пользователем.

Начиная с Ubuntu, вошедшего в мою основную учетную запись, я открываю терминал и suдля альтернативного пользователя. Затем я пытаюсь выполнить команду, чтобы запустить приложение и получить «Протокол не указан».

Это из-за UID <1000, из-за suили из-за отсутствия администратора пользователя? Как я могу заставить этого пользователя выполнить приложение с графическим интерфейсом?

Проблема не возникает из-за UID пользователя. 500 - это просто UID, и этот UID не делает его «не авторизованным» пользователем, за исключением настроек по умолчанию некоторых менеджеров отображения.

Сообщение об ошибке « Не указан протокол» звучит как сообщение об ошибке для конкретного приложения, и в этом случае оно бесполезно, но я собираюсь предположить, что ошибка заключается в том, что приложение не может связаться с вашим дисплеем X11, потому что у него нет разрешения на выполнение потому что он работает от имени другого пользователя. Приложению требуется «магический файл cookie» (секретный токен) для связи с сервером X11, чтобы другие процессы в системе, работающие под управлением других пользователей, не могли проникать на ваш дисплей, создавать окна и отслеживать нажатия клавиш. Другой системный пользователь не имеет доступа к этому волшебному cookie-файлу, поскольку разрешения установлены так, что он доступен только пользователю, запустившему среду рабочего стола (что и должно быть).

Попробуйте, запустив от имени своего исходного пользователя, скопировать файл cookie X11 в другую учетную запись:

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

затем запустите ваше приложение. Вам также может понадобиться отключить XAUTHORITYв этой оболочке тоже. Эта команда извлекает магический cookie ( xauth list) из вашего основного пользователя и добавляет его ( xauth add) туда, где его может получить другой пользователь.

В моем случае waylandпроблема с новым сервером дисплея ,

просто xhost + local:тогда другие пользователи (например, root) могут запускать программы в вашем сеансе, однако сетевые подключения не будут разрешены.

Если вы хотите разрешить клиентам с любого хоста , вы можете использовать xhost +без указания какого-либо хоста вообще. Это, однако, небезопасно , было бы лучше просто указать хост (ы), для которых вы хотите предоставить доступ к вашему сеансу.

Попробуйте что-нибудь подобное

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

источник

PS : принятый ответ не работал для меня

Предположим, вы хотите грубой силой установить связь с Х ...

Предположим, что вы уже выполняете свои команды на сервере (где работает X), иначе заставьте это работать сначала, а затем используйте 'ssh -X user @ server) от клиента;).

Существует несколько способов запуска команд xauth, например, вы можете использовать sudo, но это может привести к потере или изменению переменных среды. Следующие переменные среды должны быть сохранены: DISPLAY и XAUTHORITY. Чтобы проверить, так ли это, вы можете запустить 'echo $ XAUTHORITY' так же, как вы запускаете свои команды, но убедитесь, что вы не расширяете переменные окружения, прежде чем выполнять эти команды. Например, попробуйте: sudo bash -c 'echo "$ XAUTHORITY"', чтобы увидеть, что на самом деле представляет собой XAUTHORITY после запуска sudo (если он исчезнет, ​​вам может понадобиться добавить что-то в файл sudoers, см. В другом месте).

В конце концов, запустите следующую команду как пользователь, с которым вы хотите получить доступ, на сервере:

xauth info

Это покажет «файл авторизации», который будет использоваться (/root/.Xauthority по умолчанию, для root или что-то вроде /home/theuser/.Xauthority). Если он показывает правильный файл .Xauthority, тогда вам не нужно беспокоиться о переменной среды XAUTHORITY (на самом деле, я не знаю, когда это произойдет, за исключением случаев, когда вы хотите манипулировать нестандартным местом этого файла ).

Удалите этот файл (если он вообще существует):

rm /root/.Xauthority

Замените /root/.Xauthorityфайл XAUTHORITY на ваш случай.

Создайте его заново, но пусто (это необходимо для большого количества команд):

touch /root/.Xauthority

На этом этапе вы получите сообщение об отсутствии протокола , даже если вы получили Invalid MIT-MAGIC-COOKIE-1 ранее. Найдите файл авторизации, который X-сервер использует в данный момент:

ps aux | grep Xorg

Это должно показать что-то вроде:

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

Имя файла после -auth- это то, что вам нужно в следующей команде. Запустите это как root:

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

Это перечисляет 32-значный шестнадцатеричный ключ. Например, вывод может быть:

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

Используйте это, чтобы сгенерировать ваш файл .Xauthority (как пользователь, которому нужно снова войти):

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

замените 'c0eaf749aa252101a0f57d5087089db7' тем, что было возвращено командой list для вас. Теперь ваш .Xauthority должен иметь размер 51 байт, и вы можете подключиться к X-серверу (снова).

У меня была эта ошибка «Протокол не указан», когда я запускал экземпляр Selenium 3.3.1 из сценария upstart, а затем использовал драйвер Chrome в Selenium. Selenium работал под тем же пользователем, что и X11, и переменная среды оболочки DISPLAY была установлена ​​правильно. Что интересно, эта ошибка не произошла, когда я использовал драйвер Firefox. Установка переменной среды оболочки XAUTHORITY внутри сценария upstart для указания значения $ XAUTHORITY активного пользователя X11 исправила ошибку для драйвера Chrome.

Кстати, ошибка «Протокол не указан» был тщательно скрыт драйвером Chrome / Chrome, и его было непросто найти. Я заметил, что Chrome продолжал создавать каталоги по шаблону /tmp/.org.chromium.Chromium.*, но они быстро исчезали. Мне удалось заметить, что они содержали файл chrome_debug.logс сообщением «Не удается открыть дисплей». Я подумал, что это было довольно странно, так как я убедился, что процесс Selenium имел правильный DISPLAY, /proc/$pid/environи straceболее тщательно изучил результаты процесса Selenium, что выявило «протокол не указан», что в конечном итоге привело меня к этому вопросу.

Эту ошибку можно воспроизвести, отключив XAUTHORITY и попытавшись запустить какой-нибудь клиент X11. Например:

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

Это было просто. Проблема возникает, когда вы находитесь в root sate и хотите использовать gksu. Просто выйдите из корневого состояния и попробуйте снова

Просто введите это в свой терминал xhost +SI:localuser:rootпосле того, как вы напечатаете, export DISPLAY=:0.0затем попробуйте снова

Используя подсказки в принятых ответах, я смог решить проблему по-другому:

1. Найдите файл Xauth в учетной записи, которая работает (Xauth1)
2. Найдите файл Xauth в учетной записи, которая не (Xauth2)
3. Скопируйте Xauth1 в Xauth2
4. Изменить разрешения Xauth2

В коде:

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

Пусть говорит, что вы пытаетесь получить доступ к GUI как user2 ( обычный пользователь ), тогда Вам нужно загрузить установочный интерфейс как user2 .

Попробуйте следовать этому:

Войдите в систему как root :

sudo su

Проверьте сервер x:

xclock

Если вы видите, что часы работают, это хорошо, теперь попробуйте запустить это:

xhost

Результат должен выглядеть так:

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

Теперь позвольте user2 получить доступ к xhost

xhost +SI:localuser:user2

Теперь попробуйте снова войти в user2 и попробуйте открыть любую из программ GUI.