Несколько вещей, которые приходят на ум:
Я не думаю, что это - полностью проблема удара.
В комментарии Вы сказали наблюдение этой ошибки после выполнения
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
в другую учетную запись или делают что-то подобное; если Вы просто входите в учетную запись, полномочия корректны.
Как долговременный пользователь Linux я недавно настроил новую Ubuntu 64 бита 12.04 систем LTS и был мистифицирован относительно того, почему мои сценарии удара не работали — отклоненное разрешение — и я впоследствии нашел этот поток. Я думал, что проблема могла бы произойти из-за чего-то в новой ОС.
В конце оказывается, что я глупо использовал инструмент UI для установки полномочий на моем /home
каталог и проблема были связаны с диском. Безусловно, я создал a temp
каталог на /opt
и найденный моими сценариями работал бы очень хорошо оттуда. После того как я зафиксировал /home
полномочия диска все вернулось к нормальному.
Одна небольшая тайна решена. вздох
На самом деле причина этого состоит в том, что udev конкретно устанавливает полномочия на 0620 на tty устройствах, и su не изменяет или владение или полномочия, ни если он. По моему мнению, это оставляет нас в ситуации, которая делает/dev/std* непортативным.
Простое решение состоит в том, чтобы поместить "mesg y" в/etc/profile (или безотносительно высокоуровневого профиля, который Вам нравится использовать), поскольку это изменяет полномочия Вашего tty устройства к 0622. Мне действительно не нравится это, но это, вероятно, лучше, чем изменение правил udev.
Это старый вопрос, но я думаю, что он все еще очень актуален, поэтому я нашел решение, которое здесь не упоминается.
Я столкнулся с этим вопросом, поскольку я также видел проблемы с переключением учетной записи su, выполняющей команду, подобную этой, в bash:
echo test > /dev/stderr
Поскольку все, что я пытаюсь сделать, это перенаправить stdout на stderr, следующее достигает того же, и это работает даже в переключенной учетной записи su:
echo test 1>&2
Поскольку я хотел, чтобы одни и те же строки шли в консоль (или файл журнала -, если перенаправить ), где пользователь увидит их дословно, и в фильтр, который Чтобы разобрать их, я использовал 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
pam_ck_connector.so
для). – Mikel 13.05.2012, 23:12/proc/self/fd/1
обновляли его полномочия, но это бессмысленно, так как это - символьная ссылка. Происходит на Fedora также, который, кажется, исключает ConsoleKit. – Mikel 14.05.2012, 07:13