удар:/dev/stderr: Разрешение отклонено

Несколько вещей, которые приходят на ум:

  • Используйте tcpdump, wireshark или другого пакетного инспектора Ethernet, чтобы видеть, отправляет ли плата пакеты в неправильный адрес или не отправляет что-нибудь вообще.
  • Что Вы имеете на последовательной консоли (если существует один)?
  • Попытайтесь соединить удаленный отладчик ядра.
  • Попытайтесь работать в средстве моделирования, если у Вас есть средство моделирования, в котором можно воспроизвести проблему.
  • Вместо того, чтобы просто выбрать ядро, помещенное файловая система начальной-загрузки-и-корня во флэш-память или загрузка корневая файловая система к псевдодиску.

19
13.04.2017, 15:36
5 ответов

Я не думаю, что это - полностью проблема удара.

В комментарии Вы сказали наблюдение этой ошибки после выполнения

sudo su username2

при входе в систему как username. Это su это инициировало проблему.

/dev/stdout символьная ссылка на /proc/self/fd/1, который является символьной ссылкой на, например, /dev/pts/1. /dev/pts/1, то, которое является псевдотерминалом, принадлежит, и перезаписываемое, username; то владение предоставили когда username зарегистрированный. Когда Вы sudo su username2, владение /dev/pts/1 не изменяется, и username2 не имеет разрешения записи.

Я утверждал бы, что это - ошибка. /dev/stdout должен быть, в действительности, псевдоним для потока стандартного вывода, но здесь мы видим ситуацию где echo hello работы, но echo hello > /dev/stdout сбои.

Одно обходное решение должно было бы сделать username2 член группы tty, но это дало бы username2 разрешение записать в любой tty, который является, вероятно, нежелательным.

Другое обходное решение должно было бы войти в username2 считайте вместо использования su, так, чтобы /dev/stdout точки к недавно выделенному псевдотерминалу, принадлежавшему username2. Это не могло бы быть практично.

Другое обходное решение должно было бы изменить Ваши сценарии, таким образом, они не обращаются к /dev/stdout и /dev/stderr; например, замените это:

echo OUT > /dev/stdout
echo ERR > /dev/stderr

этим:

echo OUT
echo ERR 1>&2

Я вижу это в своей собственной системе, Ubuntu 12.04, с ударом 4.2.24 - даже при том, что документ удара (info bash) в моей системе говорит это /dev/stdout и /dev/stderr рассматриваются особенно при использовании в перенаправлениях. Но даже если удар не рассматривает те имена особенно, они должны все еще действовать как эквиваленты для стандартных потоков ввода-вывода. (POSIX не упоминает /dev/std{in,out,err}, таким образом, может быть трудно утверждать, что это - ошибка.)

Смотря на старые версии удара, документация подразумевает это /dev/stdout и др. рассматриваются особенно, существуют ли файлы или нет. Функция была представлена в ударе 2.04, и NEWS файл для той версии говорит:

Код перенаправления теперь обрабатывает несколько имен файлов особенно:/dev/fd/N,/dev/stdin,/dev/stdout, и/dev/stderr, присутствуют ли они в файловой системе.

Но если Вы исследуете исходный код (redir.c), Вы будете видеть, что та специальная обработка включена только если символ HAVE_DEV_STDIN определяется (это определяется, когда удар создается из источника).

Насколько я могу сказать, никакая выпущенная версия удара не сделала специальную обработку /dev/stdout и др. безусловный - если некоторое распределение не исправило его.

Таким образом, другое обходное решение (который я не попробовал) должно было бы захватить источники удара, изменить redir.c сделать специальное предложение /dev/* обработка безусловного, и использование восстановленная версия, а не та, которая шла системой. Это - вероятно, излишество, все же.

СВОДКА:

Ваша ОС, как моя, не обрабатывает владение и полномочия /dev/stdout и /dev/stderr правильно. колотите, предположительно, рассматривает эти имена особенно в перенаправлениях, но на самом деле это делает так, только если файлы не существуют. Это не имело бы значения если /dev/stdout и /dev/stderr работавший правильно. Эта проблема только обнаруживается когда Вы su в другую учетную запись или делают что-то подобное; если Вы просто входите в учетную запись, полномочия корректны.

41
27.01.2020, 19:44
  • 1
    Владение TTY должно измениться. Это что ConsoleKit (иначе. pam_ck_connector.so для). –  Mikel 13.05.2012, 23:12
  • 2
    На самом деле я мог быть неправым. Должен будет вырыть больше. –  Mikel 14.05.2012, 07:11
  • 3
    В моих системах, /proc/self/fd/1 обновляли его полномочия, но это бессмысленно, так как это - символьная ссылка. Происходит на Fedora также, который, кажется, исключает ConsoleKit. –  Mikel 14.05.2012, 07:13

Как долговременный пользователь Linux я недавно настроил новую Ubuntu 64 бита 12.04 систем LTS и был мистифицирован относительно того, почему мои сценарии удара не работали — отклоненное разрешение — и я впоследствии нашел этот поток. Я думал, что проблема могла бы произойти из-за чего-то в новой ОС.

В конце оказывается, что я глупо использовал инструмент UI для установки полномочий на моем /home каталог и проблема были связаны с диском. Безусловно, я создал a temp каталог на /opt и найденный моими сценариями работал бы очень хорошо оттуда. После того как я зафиксировал /home полномочия диска все вернулось к нормальному.

Одна небольшая тайна решена. вздох

0
27.01.2020, 19:44
  • 1
    Это, должно быть, было другой ошибкой. Изменение чего-то в / домой не влияет на/dev. –  ott-- 23.08.2013, 22:31

На самом деле причина этого состоит в том, что udev конкретно устанавливает полномочия на 0620 на tty устройствах, и su не изменяет или владение или полномочия, ни если он. По моему мнению, это оставляет нас в ситуации, которая делает/dev/std* непортативным.

Простое решение состоит в том, чтобы поместить "mesg y" в/etc/profile (или безотносительно высокоуровневого профиля, который Вам нравится использовать), поскольку это изменяет полномочия Вашего tty устройства к 0622. Мне действительно не нравится это, но это, вероятно, лучше, чем изменение правил udev.

1
27.01.2020, 19:44

Это старый вопрос, но я думаю, что он все еще очень актуален, поэтому я нашел решение, которое здесь не упоминается.

Я столкнулся с этим вопросом, поскольку я также видел проблемы с переключением учетной записи su, выполняющей команду, подобную этой, в bash:

echo test > /dev/stderr

Поскольку все, что я пытаюсь сделать, это перенаправить stdout на stderr, следующее достигает того же, и это работает даже в переключенной учетной записи su:

echo test 1>&2
0
27.01.2020, 19:44

Поскольку я хотел, чтобы одни и те же строки шли в консоль (или файл журнала -, если перенаправить ), где пользователь увидит их дословно, и в фильтр, который Чтобы разобрать их, я использовал somecommand | tee /dev/stderr | myfilter.

Это сломалось, когда пользователь попытался запустить мой скрипт послеsudo-ввода...

Работа -состоит в том, чтобы проверить, является ли /dev/stderrдоступным для записи --что будет, если

  • не было sudoвовлеченных, или
  • если стандартная ошибка перенаправляется в файл

Вот что я делаю:

if [ -w /dev/stderr ]
then
        STDERR=/dev/stderr
else
        STDERR=/dev/tty # The only reason is that stderr is a link to console
fi
...
somecommand | tee $STDERR | myfilter
0
26.05.2021, 19:36

Теги

Похожие вопросы