Право собственности на .Xauthority передается пользователю root

Каким-то образом во время игры с LightDM и Webkit Greeter право собственности на .Xauthorityфайл в моем домашнем каталоге было передано пользователю root, и я не смог войти, потому что у меня не было привилегий для блокировки файла.

Мне удалось вернуть право собственности на файл, и я мог войти снова. (После нескольких часов переустановки LightDM и его приветствий)

Так что теперь все снова работает нормально. Но я хотел бы знать, как это случилось. Это ошибка в LightDM или Greek Webkit или что-то еще?

permissions login

— s3lph
источник

Почти наверняка нет, нет. Вы либо начали X сессии в качестве корня (не знаю , как вам удалось это) или просто использовали touchили иначе писали .Xauthorityс sudo. Для более подробной информации, вам придется объяснить, что вы на самом деле делаете.

В следующий раз не переустанавливайте ничего, просто удалите ~/.Xauthorityфайл, он будет автоматически воссоздан при следующем входе в систему:

sudo rm ~/.Xauthority

Тогда авторизуйтесь нормально.

— terdon
источник

Чтобы найти, где была проблема, я однажды побежал sudo startx, что сработало. После смены владельца файла я снова смог войти в систему. Таким образом, запуск X с правами root просто исправил исходную проблему?

— s3lph

@the_Seppi нет, запуск sudo startx запустил X-сеанс, который принадлежал пользователю root, который был владельцем .Xsessionи мог войти в систему. Затем вы изменили владельца, что позволило вашему пользователю снова войти в систему. В следующий раз просто удалите файл, как я уже сказал, он автоматически воссоздается при входе в систему, и нет смысла «исправлять» его права доступа.

— Тердон

Но это исправило это. И я ничего не сделал для .Xauthority. Btw. какова цель этого файла?

— s3lph

@the_Seppi да, это исправлено. .XauthorityФайл в основном магическое число , используемое для идентификации владельца Х сессии , с тем , что другие люди не могут захватить его. Если вы запускаете сеанс X, и я вошел в систему на той же машине, я не смогу получить доступ к вашему сеансу X, если я не являюсь владельцем .Xauthorityфайла. Он создается всякий раз, когда вы входите в систему, если таковой не существует. Так что да, изменение разрешений для вашего пользователя исправит это, но так же просто удалит его.

— тердон

У меня была такая же проблема; Я понял, что попытался запустить startx от имени пользователя root после попытки восстановления после неудачного обновления, которое отключило Bluetooth. Я часами пытался вернуть графический интерфейс. Оказывается супер просто! Удалите все файлы блокировки .Xauthority, удалите файл .Xauthority и перезапустите. <rant> Такие маленькие секреты, которые так трудно найти, если вы не в курсе (или это было слишком давно с тех пор, как вы это сделали), в настоящее время делают linux плохим выбором для многих людей, которые могли бы его использовать. </ rant>

— Хлонгмор

Это случилось со мной тоже. Я думаю, что это может быть вызвано бегом

sudo graphic_application

вместо того

gksudo graphic_application

для какого-то (неизвестного) приложения. На странице помощи sudo есть параграф об этом ... прокрутите вниз до "Graphical sudo".

Смотрите также В чем разница между "gksudo nautilus" и "sudo nautilus"?

— Rmano
источник

Это не должно влиять на то .Xauthority, что создается при запуске сеанса X, оно не будет затронуто последующими запусками приложений с графическим интерфейсом.

— Terdon

@terdon вы правы --- если вы не используете startx или подобное. Я играл с Xnest, когда меня это укусило, возможно, ошибка оператора.

— Rmano