Глобальный буфер обмена не может скопировать новое содержимое, если запущен браузер на основе webkit
Это - вероятно, ошибка в политике SELinux относительно semanage двоичный файл (который имеет его собственный контекст semanage_t) и /tmp каталог, который имеет его собственный контекст также - tmp_t.
Я смог воспроизвести почти те же результаты на своем CentOS 5.6.
# file /tmp/users.txt /tmp/users.txt: ERROR: cannot open `/tmp/users.txt' (No such file or directory) # semanage login -l > /tmp/users.txt # file /tmp/users.txt /tmp/users.txt: empty # semanage login -l >> /tmp/users.txt # file /tmp/users.txt /tmp/users.txt: empty
Когда я пытался использовать файл в другом каталоге, я получил нормальные результаты
# file /root/users.txt /root/users.txt: ERROR: cannot open `/root/users.txt' (No such file or directory) # semanage login -l > /root/users.txt # file /root/users.txt /root/users.txt: ASCII text
Различие между /tmp и /root их контексты
# ls -Zd /root/ drwxr-x--- root root root:object_r:user_home_dir_t /root/ # ls -Zd /tmp/ drwxrwxrwt root root system_u:object_r:tmp_t /tmp/
И наконец, после попытки перенаправить в файл в /tmp У меня есть следующие ошибки в /var/log/audit/audit.log
type=AVC msg=audit(1310971817.808:163242): avc: denied { write } for pid=10782 comm="semanage" path="/tmp/users.txt" dev=dm
-0 ino=37093377 scontext=user_u:system_r:semanage_t:s0 tcontext=user_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1310971838.888:163255): avc: denied { append } for pid=11372 comm="semanage" path="/tmp/users.txt" dev=d
m-0 ino=37093377 scontext=user_u:system_r:semanage_t:s0 tcontext=user_u:object_r:tmp_t:s0 tclass=file
Интересное примечание: перенаправление semanage вывод к трубопроводам хорошо
#semanage login -l | tee /tmp/users.txt > /tmp/users1.txt # file /tmp/users.txt /tmp/users.txt: ASCII text # file /tmp/users1.txt /tmp/users1.txt: ASCII text
Частичный ответ: на самом деле в X нет глобального буфера обмена. Как описано в статье в Википедии, два приложения должны обмениваться данными для копирования и вставки. Атомы X, хранящиеся в корневом окне, описывают «владельца» первичного или вторичного выбора, и приложение, которое хочет скопировать или вставить, должно узнать владельца и связаться с ним для выполнения фактической вставки.
Если после запуска браузера на основе webkit вы всегда вставляете последнее выбранное, это означает, что webkit каким-то образом портит хранилище прав собственности и не позволяет приложениям устанавливать его.
Вы можете использовать xtrace для отслеживания всех событий X, и я бы использовал это для сравнения «здорового» вырезания и вставки с тем, что происходит после запуска webkit. Я еще не делал этого сам, поэтому я не могу дать пошаговую инструкцию.
Также может быть интересно запустить xclipboard, который должен взять на себя право собственности на выборки (опять же см. статью в Википедии), и посмотреть, что произойдет.