Автор Тема: Ошибки в работе Custom URL протокола в altlinux под правами пользователя  (Прочитано 719 раз)

Оффлайн Dron.ru

  • Начинающий
  • *
  • Сообщений: 13
Доброе утро, коллеги.

Пришло время перевести свою организацию на linux, со всеми серверами и самописными сервисами. Опыт работы в linux нулевой, но приходится импортозамещать винду пока директор не импортозаместил этого админа :-D

Итак задача: Есть корпоративный сервер Windows 2008 R2 с web-сервером Apache и самописным кодом на perl. Пользователи подключаются к серверу через web-интерфейс по https и работают в системе. В процессе работы нажимают на ссылки вида <a href="mck:*****">*****</a> при нажатии на которые их компы на windows 7/XP запускают локальный скрипт прописанный в реестре как обработчик протокола mck. Реализовано это путем добавления своего Custom URL протокола на каждый из компьютеров пользователей. В винде это делается очень просто, но попытка настроить аналогичную схему на altlinux привела к потере времени и отрицательному результату.

Прошу помочь советом, подробности см. ниже.

Цитировать
Операционная система: ALT 10.1
Версия KDE Plasma: 5.26.4
Версия KDE Frameworks: 5.100.0
Версия Qt: 5.15.7
Версия ядра: 5.15.89-un-def-alt1 (64-бита)
Графическая платформа: Wayland
Название продукта: VMware Virtual Platform
Версия системы: None


Результаты запуска команд под правами root и user(ru)

Проверка версии xdg-mime:
[root@ALT2 ~]# xdg-mime --version
xdg-mime 1.1.3

Добавление протокола mck под правами root:
[root@ALT2 ~]# xdg-mime default mck.desktop x-scheme-handler/mck
Добавление протокола mck под правами пользователя:
[ru@ALT2 ~]$ xdg-mime default mck.desktop x-scheme-handler/mck
Проверка регистрации протокола mck под правами root (всё ok):
[root@ALT2 ~]# xdg-mime query default x-scheme-handler/mck
mck.desktop
Проверка регистрации протокола mck под правами пользователя (всё ok):
[ru@ALT2 ~]$ xdg-mime query default x-scheme-handler/mck
mck.desktop

Проверяем вручную что изменилось у root:

Цитировать
Путь: ~/.config/
Файл: mimeapps.list
Права доступа: -rw-r--r-- (root root)
Содержимое файла:
Цитировать
[Default Applications]
x-scheme-handler/mck=mck.desktop


Проверяем вручную что изменилось у пользователя:

Путь: /home/ru/.config/
Файл: mimeapps.list
Права доступа: -rw-r--r-- (ru ru)
Содержимое файла:
Цитировать
[Default Applications]
x-scheme-handler/mck=mck.desktop


Проверяем файл mck.desktop (добавил избыточные права доступа к этому файлу для всех пользователей на период тестирования бага):

Путь: /usr/share/applications/
Файл: mck.desktop
Права доступа: -rwxrwxrwx (root root)
Содержимое файла:
Цитировать
[Desktop Entry]
Name=mck
Comment=mck
Exec=/home/ru/Desktop/mck.sh
Terminal=false
Type=Application
MimeType=x-scheme-handler/mck


Проверяем файл mck.sh который должен запускаться при нажатии пользователем в браузере на ссылку вида <a href="mck:*****">*****</a>. В данном случае файл просто создает папку на рабочем столе пользователя дабы показать что он сработал. Сам файл mck.sh находится на рабочем столе пользователя на всякий случай дабы исключить возможные ошибки с ограничением доступа к файлу под правами пользователя на этапе тестирования.

Путь: /home/ru/Desktop/
Файл: mck.sh
Права доступа: -rwxrwxrwx (root root)
Содержимое файла:
#!/bin/sh
mkdir /home/ru/Desktop/del1
chmod 777 /home/ru/Desktop/del1

Проверяем работу протокола с помощью xdg-open под правами root:
[root@ALT2 ~]# xdg-open mck:xxxxxxКоманда срабатывает без ошибок и сообщений, на рабочем столе пользователя ru появляется каталог del1, скрипт mck.sh
 сработал без ошибок.


Проверяем работу протокола с помощью xdg-open под правами пользователя:
[ru@ALT2 ~]$ xdg-open mck:xxxxxx
VMware: No 3D enabled (0, Выполнено).
libEGL warning: egl: failed to create dri2 screen
[ru@ALT2 ~]$ VMware: No 3D enabled (0, Выполнено).
libEGL warning: egl: failed to create dri2 screen
kf.kio.core: Protocol Class of url QUrl("mck:xxxxxx") , isn't ':local', cancelling job.
kf.kio.core: couldn't create slave: "Неизвестный протокол «mck»."
kf.kio.slaves.file: readData() returned -1
Выскакивает окно с ошибкой:
Цитировать
Заголовок окна: "Ошибка KIOExec"
Текст сообщения: "Ошибка создания вспомогательного процесса ввода/вывода. Неизвестный протокол mck"

Проверяем работу протокола под правами пользователя в реальных условиях:

Создаем файл /home/ru/Desktop/test.html
Содержимое файла:
<html>
<body>
<a href="mck:test">test</a>
</body>
</html>
Открываем браузером Chromium-Gost, жмём на ссылку test, выскакивает сообщение "Открыть приложение xdg-open?", после нажатия в браузере на кнопку "Да" выскакивает системное окно с ошибкой:
Заголовок окна: "Ошибка KIOExec"
Текст сообщения: "Ошибка создания вспомогательного процесса ввода/вывода. Неизвестный протокол mck"

При этом файл mck.sh не запускается, но если его переименовать, то получаем:

[ru@ALT2 ~]$ xdg-open mck:xxxxxx
VMware: No 3D enabled (0, Выполнено).
libEGL warning: egl: failed to create dri2 screen
kf.kio.gui: "Невозможно найти программу «/home/ru/Desktop/mck.sh»"
То есть под правами пользователя протокол всё-таки зарегистрирован, система хочет запустить файл mck.sh, проверяет его наличие и до стадии запуска файла срабатывает без ошибок.

Есть идеи в каком направлении копать?
Обрабатывать протокол под правами админа не вариант - это будет огромная дыра в безопасности т.к. в рабочем варианте скрипту будут передаваться управляющие команды по протоколу mck.

« Последнее редактирование: 31.01.2023 17:29:28 от ruslandh »

Оффлайн Dron.ru

  • Начинающий
  • *
  • Сообщений: 13
Произвел аналогичные настройки на другом виртуальном хосте altlinux и всё прошло без ошибок:

Host: Alt1 Kernel: 5.10.82-std-def-alt1 x86_64 bits: 64
Desktop: MATE 1.26.0 Distro: ALT Workstation 10.1
Type: Vmware System: VMware product: VMware Virtual Platform v: N/A
Device-1: VMware SVGA II Adapter driver: vmwgfx v: 2.18.0.0
Display: x11 server: X.Org 1.20.14 driver: loaded: vmware
OpenGL: renderer: llvmpipe (LLVM 11.0.1 256 bits) v: 4.5 Mesa 22.0.4
Shell: Bash inxi: 3.3.04

Оба виртуальных хоста свежеустановленные и отличаются только исходным образом и обновленным ядром:
1. Хост без ошибок: свежий образ alt-workstation-10.0-x86_64.iso, ядро 5.10.82-std-def-alt1 x86_64 bits: 64
2. Хост с ошибками: свежий образ alt-kworkstation-10.1-install-x86_64.iso, ядро 5.15.89-un-def-alt1 (64-бита) (обновил софт и ядро перед настройкой Custom URL protocol)


Оффлайн Dron.ru

  • Начинающий
  • *
  • Сообщений: 13
Откатил проблемный хост основанный на образе alt-kworkstation-10.1-install-x86_64.iso до исходной версии (ALT 10.1; KDE Plasma 5.26.4; KDE Frameworks 5.100.0; Qt 5.15.7; ядро 5.15.72-un-def-alt1 64 бит; Wayland), внес идентичные настройки, получаю ту же ошибку - "Неизвестный протокол mck"

Оффлайн ruslandh

  • Поспешай не торопясь !
  • Модератор глобальный
  • *****
  • Сообщений: 32 251
  • Учиться .... Телепатами не рождаются, ими ....
    • Email
Извините,  частично отредактировал ваше сообщение, очень трудно читать, а тем более понять без "украшательств" ваш текст, тут уж извините, природа человека такова.

libEGL warning: egl: failed to create dri2 screen

А не связаны ваши проблемы с подобными сообщениями? Судя по логам, затрагивается kio. Возможно или скрипт не виден от пользователя, или он не имеет прав на создание каталога (?)

PS В одном случае у вас Wayland, в другом xorg. С этим тоже может быть связано.
Ну и  Vmware не самая лучшая среда виртуализации для ALT

Оффлайн Dron.ru

  • Начинающий
  • *
  • Сообщений: 13
А не связаны ваши проблемы с подобными сообщениями? Судя по логам, затрагивается kio. Возможно или скрипт не виден от пользователя, или он не имеет прав на создание каталога (?)

PS В одном случае у вас Wayland, в другом xorg. С этим тоже может быть связано.
Ну и  Vmware не самая лучшая среда виртуализации для ALT
Ручной запуск скрипта под правами пользователя проходит, значит дело не в правах доступа. Хосты запускаю с одной VMware машины на windows7. Разница только в сборке Altlinux - в одном случае свежий дистрибутив с MATE, в другом с KDE.

Цитировать
VMware: No 3D enabled (0, Выполнено).
libEGL warning: egl: failed to create dri2 screen
Эту часть ошибки убрал включив поддержку 3D в VMware, к сожалению проблема не в ней.
« Последнее редактирование: 31.01.2023 18:27:33 от Dron.ru »

Оффлайн ruslandh

  • Поспешай не торопясь !
  • Модератор глобальный
  • *****
  • Сообщений: 32 251
  • Учиться .... Телепатами не рождаются, ими ....
    • Email
https://ru.wikipedia.org/wiki/KIO
Цитировать
KIO поддерживает протоколы HTTP, FTP, SMB, SSH, FISH, SVN, TAR)[6][7][8] и иные, в том числе монтирование файловых систем через FUSE.


Наверное с KIO всё сложнее
https://api.kde.org/frameworks/kio/html/classKProtocolManager.html

Оффлайн Dron.ru

  • Начинающий
  • *
  • Сообщений: 13
Проблема решена.
Что было её причиной до конца так и не понял, скорее всего ошибка возникала из-за того, что я редактировал текстовые файлы программой KWrite. Переписал все символы файлов mck.proto и mck.sh текстовым редактором mc и всё заработало. Возможно KWrite по аналогии с виндовым блокнотом добавляет невидимые символы в начало файла в зависимости от кодировки UTF-8/ANSI что вызывает неожиданные аномалии.

Оффлайн Skull

  • Глобальный модератор
  • *****
  • Сообщений: 19 916
    • Домашняя страница
    • Email
Нет, kwrite так не делает (если явно не указали в параметрах настройки).
Андрей Черепанов (cas@)

Оффлайн Dron.ru

  • Начинающий
  • *
  • Сообщений: 13
Недавнее обновление убило работу Custom URL.

Как только делаю обновление на очередном компе в офисе он перестает открывать ссылки Custom URL и вместо заданного в вызываемом скрипте действия появляется окно (см. вложение) отправки на устройство и нужный скрипт не запускается.

Подскажите в каком направлении копать или на какой модуль жаловаться в багзилле.
« Последнее редактирование: 13.09.2023 17:54:53 от Dron.ru »

Оффлайн Dron.ru

  • Начинающий
  • *
  • Сообщений: 13
Проверил на нескольких идентичных компьютерах - после обновления проблема решается повторным запуском команды xdg-mime default, но только после второй перезагрузки. Почему ввод данной команды после первой перезагрузки не дает результата не понятно.