Почему не работает «sudo cd / var / named»? [Дубликат]

Причина, по которой вы не можете сделать это, проста и в два раза

1

cd не является программой, но встроенная команда и sudo применимы только к программам.

sudo foo означает запуск программы foo с правами root

sudo cd /path возвращает

sudo: cd: command not found

, потому что cd не является программой.

2

Если бы можно было использовать sudo в cd в защищенном каталоге, то, выполнив команду sudo cd /var/named , вы были бы в этом каталоге как обычный пользователь, но обычным пользователям не разрешалось быть в этом каталоге.

Это невозможно.

Обход проблемы:

Вы можете использовать sudo -i , чтобы поднять себя к суперпользователю. Например:

sudo -i
cd /var/named 

Теперь вы вошли в систему под учетной записью root и можете использовать любые команды. По завершении введите exit , и вы вернетесь к тому, чтобы войти в систему как обычный пользователь.

Это потому, что cd не является исполняемым, это функция оболочки для изменения каталога.

Если вы запустите:

type cd

у вас получится:

  

cd - это функция оболочки

Вы можете использовать sudo -s , чтобы открыть интерактивную оболочку, а затем cd в нужную директорию:

sudo -s
cd /var/named

Чтобы вернуться к нормальной оболочке, просто нажмите Ctrl + D .

Также стоит помнить, что cd имеет статус встроенной оболочки или внешнего двоичного файла, sudo работает, создавая новый процесс для запуска указанной команды .

Почему это важно? Поскольку основной поток выполнения sudo становится чем-то очень похожим на это:

1. Оболочка запускает подпроцесс для запуска sudo с заданными параметрами
2. sudo аутентифицирует пользователя и подтверждает свое право выполнить указанную команду
3. sudo запускает подпроцесс для выполнения указанной команды
4. sudo ожидает, что подпроцесс, порожденный на шаге 3, выйдет из
5. sudo завершает работу, возвращается в оболочку
6. Подпроцесс, открытый на шаге 1, завершает работу, возвращая пользователя в приглашение оболочки

(Этот может быть технически немного некорректным, есть системный вызов, который фактически заменяет текущий процесс новым (это C библиотеки execve() ). Однако для целей этого объяснения они эквивалентны.)

Это становится важным, если учесть, что текущий рабочий каталог является свойством каждого процесса и унаследован, но не поддерживается . Поэтому, если процесс A запускает новый процесс B, процесс B начинается с того же рабочего каталога, в котором находился процесс A. (Вот почему что-то такое обычное, как ls ./ делает то, что вы ожидаете.) Но если процесс B изменяется его рабочий каталог, тогда, если процесс A не ищет его, A полностью не знает об этом изменении. (Это, в свою очередь, является причиной того, что если вы запускаете что-то вроде find / и прервите его на полпути, вы не попадете в какое-то, казалось бы, случайное место в файловой системе, просто потому, что находка, похоже, там была там он был прерван.)

Таким образом, даже если sudo cd /somewhere сделал именно то, что он говорит на жесте, к моменту выхода sudo вы вернетесь туда, где вы начали. Следовательно, эффективно с точки зрения пользователя, он становится не-оператором. Тот факт, что cd , когда он выполнялся, вызвал функцию системной библиотеки chdir() для установки нового рабочего каталога, не помогает вам, пользователю.

Как Уоррен Хилл указал, правильное решение (на самом деле я бы не позвонил это обходной путь) заключается в использовании sudo -i , которая отбрасывает вас в корневую оболочку, где вы можете свободно перемещаться по файловой системе и выполнять любые команды, которые вы чувствуете. Обратите внимание, однако, что при выходе из этой оболочки вы still вернулись туда, где вы начали в иерархии каталогов, по той же причине, что и я описал выше.

Все приведенные выше ответы верны; вот обходное решение, хотя

sudo sh -c "cd restricted-dir; some_command"

Вы также можете временно изменить разрешение. chmod 0775 путь. Убедитесь, что вы вернули его, если необходимо.