Как поломать screen sharing в Gnome

Wayland уже пробовал?

Оно в вайленде работает, вот в чем дело но я уже решил проблему

Вот нашел статью в интернете:

Если вы хотите отключить PipeWire, но сохранить звук в системе, вам нужно настроить другой звуковой сервер, например PulseAudio. PulseAudio — это стандартный звуковой сервер, который использовался в большинстве Linux-дистрибутивов до недавнего времени, когда его стал заменять PipeWire.

1. Проверка установки PulseAudio

1. Проверьте, установлен ли PulseAudio:

   rpm -q pulseaudio
   

   Если он не установлен, вы можете установить его:

   sudo zypper install pulseaudio
   

2. Убедитесь, что установлены все необходимые пакеты:

   sudo zypper install pulseaudio pulseaudio-utils pavucontrol
   

2. Отключение PipeWire и активация PulseAudio

1. Отключите PipeWire на уровне пользователя, чтобы он не запускался:

   systemctl --user disable --now pipewire pipewire-pulse
   

2. Убедитесь, что PulseAudio включен и активен:

   systemctl --user enable --now pulseaudio
   

3. Настройка PulseAudio

1. Запустите PulseAudio вручную, если он не запущен:

   pulseaudio --start
   

2. Проверьте статус PulseAudio, чтобы убедиться, что он работает:

   systemctl --user status pulseaudio
   

3. Используйте pavucontrol (PulseAudio Volume Control) для настройки звука:

   • Запустите pavucontrol в терминале или через меню приложений.
   • Убедитесь, что ваши аудиоустройства правильно выбраны в разделе «Output Devices» (Устройства вывода).
   • Отрегулируйте громкость и другие параметры.

4. Тестирование звука

Попробуйте воспроизвести любой аудиофайл или видео, чтобы проверить, работает ли звук. Если звук работает, но недостаточно хорошего качества, возможно, вам нужно настроить дополнительные параметры PulseAudio.

5. Дополнительные настройки

Если по каким-то причинам PulseAudio не работает, вы можете попробовать:

• Удалить PipeWire и его зависимости, чтобы убедиться, что они не конфликтуют:

  sudo zypper remove pipewire
  

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

  sudo reboot
  

6. Проверка конфигурации

Если у вас есть какие-либо проблемы, убедитесь, что конфигурационные файлы PulseAudio в порядке. Обычно они находятся в:

• /etc/pulse/daemon.conf
• /etc/pulse/default.pa

В этих файлах можно изменить параметры, если требуется тонкая настройка.

Заключение

После выполнения этих шагов ваш звук должен работать через PulseAudio, без использования PipeWire. Если у вас всё ещё возникают проблемы со звуком, попробуйте перезапустить аудиосервисы или проверьте настройки устройств вывода в pavucontrol.

Wayland

и вот, screen sharing заработал для всего видимого на экране. А если он работает для хромого, значит оно работает для всего что захочет.

Где там апологеты вяленого с доводами про секурность? Мол «отсутствие возможности приложению „видеть“ весь экран — фишка, а в иксах это было брешью в безопасности». Что теперь скажете?

И толку? Если у тебя X11 - любое приложение и так сможет содержимое экрана смотреть, сколько бы ты ни сносил PipeWire.

Под Wayland без явного разрешения от пользователя не выйдет посмотреть. Так в чём проблема-то?

Отслеживается именно пользователь, именно интерактивно выполнил какое-то действие, чтобы подтвердить что «сейчас вот это приложение может»? И нет механизма какому-то приложению это разрешение выдать на постоянной основе?

А можно было просто отключить скриншэринг в браузере?

И интересна природа таких страхов. Перед скриншерингом браузер всегда спрашивает - делиться экраном или нет? По сети без твоего явного открытия службы и портов никто не подключится. Как ещё может возникнуть угроза? Если это не тупо паранойя, хотелось бы услышать как злоумышленники ещё захватывают экраны.

От DE зависит. Приложение через стандартный интерфейс запрашивает, а что там на стороне DE - его не касается.

От DE зависит.

Спасибо, Кэп. Вяленый — протокол без эталонной реализации. Поэтому любой чих «от DE зависит».

Перефразирую: предусмотрено ли, что пользователь 1 раз нажмёт «разрешать OBS Studio шаринг всегда», или каждый раз пользователю придётся дополнительно отвлекаться на запрос «разрешить/запретить»?

предусмотрено ли, что пользователь 1 раз нажмёт «разрешать OBS Studio шаринг всегда», или каждый раз пользователю придётся дополнительно отвлекаться на запрос «разрешить/запретить»?

От DE зависит.

Значит протоколом не регламентировано.

И чем оно безопаснее шлагбаума посреди поля?

Перефразирую: предусмотрено ли, что пользователь 1 раз нажмёт «разрешать OBS Studio шаринг всегда», или каждый раз пользователю придётся дополнительно отвлекаться на запрос «разрешить/запретить»?

Насколько я знаю, текущие реализации все спрашивают каждый раз. Я бы может и хотел поставить галочку, что вот тут вот не спрашивать, но нет, каждый раз. Ещё отдельный геморрой, что на превью и на шаринг запрашивает отдельно, т.е. 2 запроса на каждый шаринг. А если хочешь выбрать отдельное окно, то выбирай из длинного списка 2 раза. Хорошо, что пользуюсь 2 раза в месяц. А то задолбался бы разрешать.

И чем оно безопаснее шлагбаума посреди поля?

Так не пользуйся кривыми ДЕ, где есть такая галочка. В моих порталах такой(к сожалению) нет.

PS: А так то композитор работает на уровне DRM, он вообще всё может видеть. Если композитору не доверяешь, то тут уж ничего не поделаешь - гроб,гроб,кладбище,могила.

Если композитору не доверяешь

процесс композитора как называется?

У меня браузер запрашивает, видимо через wayland-протокол захват экрана и появляется процесс hyprland-share-picker, где можно выбрать что шарить. Без этого share-picker-а расшарить экран возможности нет. Подозреваю что как-то это всё завязано на сам композитор и портал.

Я где-то говорил, что считаю проблемой возможность захвата экрана приложением каким-то?

То, чему я не доверяю, у меня запускается на отдельной физической железке без сети, или изолировано от остальной локальной. Ибо, хвала безопасному UEFI, оно может прописать себя так, что ни ребут, ни переустановка ОС не помогут.

Так не пользуйся кривыми ДЕ

Падажжи. Если «низя в захват» — это за ради безопасности, то в протоколе должно быть описано требование невозможности захвата без явного подтверждения пользователем. А если требования нет, то чо борцуны с небезопасностью Вяленый не ругают за то, что в нём это не регламентировано?

Насколько я знаю, текущие реализации все спрашивают каждый раз

Или ты не нашёл где прописать нужное разрешение. Нет же гарантий, что какой-нибудь соцуслуги.deb при установке не пропишет такое разрешение себе и не будет Пашке Цукерделле твой экран стримить. И чо тогда иксы за это ругали? Или это таки надуманная проблема, лишь бы пропихнуть неполноценную замену в прод?

то в протоколе должно быть описано требование невозможности захвата без явного подтверждения пользователем.

А как ты это в протоколе опишешь так, чтобы писатели ДЕ не смогли это обойти? Можно только сказать что «так делать надо», но ты сам себе можешь написать композитор, который за тебя кнопку согласия нажимать будет и никакой протокол тебе в этом помешать не сможет.

Нет же гарантий, что какой-нибудь соцуслуги.deb при установке не пропишет такое разрешение себе и не будет Пашке Цукерделле твой экран стримить.

Так можно и ядерный модуль себе установить, который стриммить будет. Но при чем тут вяленый и его протоколы?

Как по мне, разница с иксами в том, что раньше ты этого запретить не мог, а сейчас надо ещё постараться чтобы разрешить. Вот и вся разница. Но секурнось всё же выше. Хоть мне она и нах не нужна.

предусмотрено ли, что пользователь 1 раз нажмёт «разрешать OBS Studio шаринг всегда», или каждый раз пользователю придётся дополнительно отвлекаться на запрос «разрешить/запретить»?

Предусмотрено.

persist_mode (u)

How this session should persist. Default is 0. Accepted values are:

0: Do not persist (default)

1: Permissions persist as long as the application is running

2: Permissions persist until explicitly revoked

Setting persist_mode is only allowed for screen cast sessions. Persistent remote desktop screen cast sessions can only be handled via the Remote Desktop interface.

If the permission for the session to persist is granted, a restore token will be returned via the org.freedesktop.portal.Request::Response signal of the org.freedesktop.portal.ScreenCast.Start method.

А как ты это в протоколе опишешь так, чтобы писатели ДЕ не смогли это обойти?

Прямо буквально и описать. А тем, кто не по стандарту реализуют, пользователи сами в багтрекере сообщат.

Чем строчка про «явно просить подтверждение» отличается от любой другой в описании протокола? Не выполняешь требования — значит не совместим.

Так можно и ядерный модуль себе установить, который стриммить будет. Но при чем тут вяленый и его протоколы?

Ты это кукаретикам, что в защиту вяленого лужу газифицировали «низя шарить ради безопасности». А этот аспект в протоколе вообще не оговаривается. Можно шарить/низя шарить протоколу фиолетово.

Но секурнось всё же выше.

Ты, поди, веришь и в то, что рамка металлодетектора в аэропорту уровень твоей безопасности повышает?

а сейчас надо ещё постараться чтобы разрешить … Хоть мне она и нах не нужна

Вот. Ключевое. Профита ноль, а жизнь усложнили.

Ты это кукаретикам, что в защиту вяленого лужу газифицировали «низя шарить ради безопасности». А этот аспект в протоколе вообще не оговаривается. Можно шарить/низя шарить протоколу фиолетово.

Все же разница, с тем, что даже если захочешь, то фиг запретишь(ну если не рассматривать отдельные Х для приложения) чужие окна смотреть - есть. А у вяленда протокол дает такую возможность и все адекватные ДЕ её реализуют корректно(пока не доказано обратного).