Ubuntu выполнить команду от имени www data
Обновлено: 03.07.2024
Пытаюсь сделать это:
sudo echo no > /etc/pure-ftpd/conf/someparam
На что мне отвечают:
Новые пользователи довольно часто сталкиваются с такой ошибкой, как ошибка отказано в доступе Linux. Если вы только что перешли с Windows, то можете еще не знать всех особенностей операционной системы Linux и почему возникает такая проблема.
В этой статье мы рассмотрим причины ошибки access denied linux, а также как ее обойти.
Ошибка отказано в доступе Linux
Наиболее часто такая ошибка встречается, в таких случаях:
- Вы пытаетесь выполнить команду в терминале;
- Вы пытаетесь примонтировать внешний носитель с помощью файлового менеджера;
- Вы пытаетесь запустить системный сервис и находите такую ошибку в логе.
Многие программы проверяют после запуска от какого пользователя они запущены и говорят, что их нужно запускать от имени суперпользователя, но так ведут себя не все. Например, команда ls вернет ошибку отказано в доступе linux если вы попытаетесь посмотреть содержимое каталога суперпользователя:
Но эта же команда нормально отработает нормально при использовании команды sudo:
Другой случай, это если вы обнаруживаете проблему в логах какого-либо системного сервиса, например, веб-сервера Apache. Казалось бы, должно было быть все верно, потому что запуск и так выполняется от имени суперпользователя.
Но нет, сервисы не только запускаются от имени суперпользователя, но потом, для увеличения безопасности они меняют пользователя на обычного, не привелигированного. Например, Apache работает от имени пользователя apache или www-data. Уже от имени этого пользователя программа пытается получить доступ к файловой системе.
Если нужная папка не доступна этому пользователю для чтения то вы получите ошибку access denied linux. Обычно, в логе программа сообщает какая папка или файл нужен когда происходит ошибка.
Вам просто нужно поменять на него права с помощью утилиты chmod или изменить владельца chown. Причем, нужно чтобы ко всем подкаталогам на пути к целевому каталогу был доступ у программы. Например, нельзя так чтобы права на чтение /home/ не было, а на /home/user/ было. Так не пройдет.
Права разрешающие чтение и запись владельцу и только чтение для группы и остальных вставляются командой:
sudo chmod 755 /путь/к/файлу
Или для смены прав для всех файлов в каталоге и самого каталога:
sudo chmod -R 755 /путь/к/каталогу
Или вы можете изменить владельца, обычно, это более безопасная и распространенная практика:
sudo chown пользователь /путь/к/файлу
$ sudo chown -R пользователь /путь/к/каталогу
Имя пользователя, от имени которого работает сервис вы можете посмотреть с помощью команды:
sudo ps aux | grep имя_сервиса
После того как вы установите правильные права, ошибка отказано в доступе linux больше не будет встречаться.
Выводы
В этой статье мы рассмотрели что делать если случается ошибка нет доступа linux, а также почему она возникает. Надеюсь, эта информация была полезной для вас. Если остались вопросы, спрашивайте в комментариях!
У меня была проблема с Wi-Fi, которая до сих пор не решена из-за проблемы, которая возникла, когда я пытался ее решить.
Я нашел это решение для Wi-Fi, поэтому попробовал его:
Вставьте в конфиг этот текст
Я заметил, что у меня не было разрешения на запись или выполнение файла, поэтому я попытался использовать chmod решить проблему. Это упорядоченный список всех операций, которые я сделал и которые привели к проблеме этого вопроса:
После третьей или четвертой команды (я не уверен, какая из них) я потерял свои права администратора; на самом деле, если я пытаюсь использовать команду sudo он выводит 3 строки, которые я переведу как можно лучше:
На терминале отображается
Теперь, когда я открываю терминал, он выводит мне строку bash /etc/profile: Permission denied, которую я никогда раньше не видел, и пропущенная часть имени необычна, потому что вместо нее следует писать zenoraiser.
Что вы предлагаете мне сделать?
2 ответа
Там нет необходимости выполнять chmod вообще при использовании sudo редактировать файл, хотя вы не должны использовать sudo gedit (скорее sudo -H gedit например)
Поскольку вы не меняли рекурсивные разрешения, вы можете решить проблему довольно легко.
В реальной среде определите (поврежденный) корневой раздел на диске, используя sudo fdisk -l
У меня есть приложение Symfony2 на моей Ubuntu. Symfony имеет множество полезных консольных команд (например, php app/console cache:clear or php app/console assets:install web ).
Проблема в том, что если я запускаю их как root пользователь, у вновь сгенерированных файлов будет root:root пользователь / группа, и если я захожу на свой веб-сайт, я получаю ошибки (потому что apache не может читать / изменять эти файлы -> они должны иметься www-data:www-data ).
Запуск chown www-data:www-data решает проблему, но запускать ее каждый раз, когда я очищаю кеш, не является решением.
Как я могу настроить PHP CLI, чтобы он всегда работал как пользователь / группа www-данных?
Как запустить команду от имени другого пользователя (будучи пользователем root, запустите ее как www-data)?
Запустите команду от имени другого пользователя один раз:
Это должно работать, если вы root .
Что касается всегда запуска php как www-data , есть несколько возможностей. Вы можете создать простую оболочку. Если /usr/bin/php это только софт-ссылка /usr/bin/php5 или подобное, это упрощает. Просто замените программную ссылку (НЕ файл php5 ) на скрипт вроде этого:
Это не проверено, хотя. Также имейте в виду, что это ВСЕГДА будет пытаться запускаться php5 от имени пользователя www-data , даже если пользователь может root и не иметь разрешения на это. И это также может быть не то, что вы действительно хотите. Некоторые установленные службы могут столкнуться с проблемами при попытке запустить php.
(Возможно, лучше) решение применить это только к root может заключаться в том, чтобы оставить программную ссылку в /usr/bin/php покое и вместо нее поместить скрипт /root/bin . Затем добавить эту папку в PATH через .bashrc , .profile или аналогичный. Если у вас есть /etc/skel/.profile , это может указать, как это делается:
После того, как это в вашем .bashrc , .profile или подобном, каждой новой оболочке открытия позволит вам напрямую выполнить любые исполняемые файлы (+ х) $HOME/bin ( /root/bin для корня).
Подсказка: вы можете захотеть назвать скрипт-обертку как-то так, phpwww чтобы вы явно указали php script.php или phpwww script.php решили, хотите ли вы обычный или sudo'ed php.
Другое решение - простой псевдоним. Поместите это в вашем .bashrc , .profile или аналогичном:
Моя ЛАМПА настроена для работы в качестве user:www-data , и все файлы и папки создаются с такими разрешениями.
У меня есть настройки для crontab как user @ ubuntu.
Так что я делаю crontab -e и использую эту команду:
По сути, эта команда просто создает файл кэша в указанном месте (никаких проблем с этим), но этот файл кэша создается с помощью user: пользовательские права доступа не user:www-data .
Как я могу сделать так, чтобы он по умолчанию создавал файл с user:www-data разрешениями?
Я не могу пойти и chown каждый раз, когда файл воссоздается.
4 ответа
Вы также можете запустить crontab с аргументом -u , чтобы отредактировать crontab для конкретного пользователя:
Вы можете записать свою запись в системный crontab /etc/crontab , который принимает дополнительный аргумент, определяющий пользователя для запуска от имени (обычно root, но может быть www-data).
Ваша строка станет:
Или вы можете отредактировать crontab пользовательских www-данных с помощью su :
Я хотел бы добавить другой подход. Как уже упоминали другие люди, Ubuntu (16.04 здесь) и crontab www-data кажутся ненадежными (может, это вопрос безопасности?).
Как бы то ни было, в нашей компании нам нравится, чтобы все cronjobs на сервере были легко доступны, поэтому вы ничего не пропустите. В то же время мы не хотим запускать все (что угодно!) От имени пользователя root.
Поэтому мы запускаем
Как вы обычно делаете, и затем мы указываем команду как
Это будет выполнять / path / to / command как www-data, в то время как хранение cronjob в корневом файле cronjobs (и это всегда будет работать правильно). Преимущество заключается в том, что вы можете записывать лог-файлы как root (для максимальной безопасности), используя каналы.
Обратите внимание, что мы передаем нашу предпочтительную оболочку, это также может быть / bin / sh для более простой оболочки (нам просто нравятся полные возможности bash). В Www-data не указана оболочка, поэтому вы получите ошибки без нее. Обычно cron запускает задания только с / bin / sh.
Для выполнения crontab как пользовательских www-данных, можно использовать следующую команду:
Затем Вы пишете строку, например, для выполнения php файла каждые 15 минут:
При сохранении его Вас спросит редактор:
Сохраните его там, никакие заботы. crontab -e открывает файл в/tmp вместо фактического crontab так, чтобы он мог проверить Ваш новый crontab на наличие ошибок и препятствовать тому, чтобы Вы перезаписали свой фактический crontab с теми ошибками. Если не будет никаких ошибок, то Ваш фактический crontab будет обновлен. Если бы crontab-e просто записал прямо в Ваш фактический crontab, то Вы рискнули бы сдувать свой весь crontab.
Ubuntu Server - административные права пользователей.
Как показывает читательский отклик, вопрос разделения административных прав в Ubuntu до сих пор остается малопонятным для большинства начинающих администраторов, поэтому мы решили данным материалом внести некоторую ясность в данный вопрос. Поэтому если вы не знаете чем su отличается от sudo, куда спрятали root'а и т.д. и т.п. - самое время приступить к изучению нашей статьи.
Начнем с небольшого отступления. Система административных прав Linux восходит корнями к ОС Unix и поэтому имеет много общего с другими Unix-like системами: BSD, Solaris, MacOS. В тоже время различные дистрибутивы имеют свои особенности реализации отдельных моментов, поэтому конкретные примеры мы будем приводить относительно семейства Ubuntu, однако знание общих правил позволит вам без труда разобраться в среде любой другой Unix-like ОС.
Всей полнотой административных прав в Linux обладает пользователь root, ограничить которого в правах невозможно, поэтому повседневная работа от лица данного пользователя крайне нежелательна: неосторожные действия пользователя могут привести к повреждению системы, а компрометация данной учетной записи даст злоумышленнику неограниченный доступ к системе.
Поэтому в Linux принята иная схема, все пользователи, включая администраторов, работают под ограниченной учетной записью, а для выполнения административных действий используют один из механизмов повышения прав. Для этого можно повысить права с помощью утилиты sudo или войти под именем суперпользователя (root'а) не завершая текущий сеанс с помощью команды su. Многие ошибочно путают эти два механизма, поэтому разберем их подробнее.
Команда su позволяет войти в систему под именем другого пользователя (не обязательно root) не завершая текущий сеанс. Так команда:
позволит войти в систему от имени пользователя petrov, пользовательское окружение (домашняя папка) также будут изменены на принадлежащие этому пользователю.
Команда su без указания имени пользователя позволяет войти под учетной записью root'а. Однако данный способ имеет один существенный недостаток - для входа от имени другого пользователя нужно знать его пароль. Если у вас несколько администраторов, то каждый из них будет знать пароль суперпользователя и ограничить в правах вы их не сможете.
К тому же это небезопасно, знание пароля суперпользователя и возможность входа под его именем в случае компрометации может привести к полной потере контроля над системой.
Что будет если мы попробуем таким образом повысить права в Ubuntu? У нас ничего не получится, так как мы не знаем пароля пользователя root, в тоже время никто не мешает нам войти под иным пользователем.
"Подождите!" - скажет иной пользователь, - "а разве права root'а не получает первый созданный пользователь, которого мы указываем при установке?" Действительно, административные задачи можно выполнить только от имени созданного при установке пользователя, при попытке сделать это от имени другого пользователя нас постигнет неудача.
Здесь мы вплотную подходим к второму механизму повышения прав - утилите sudo. Однако прежде чем переходить к ее изучению стоит внести ясность: права суперпользователя (root) в Ubuntu принадлежат учетной записи root, которая по умолчанию отключена. Поэтому повысить права с помощью команды su не представляется возможным.
Основным механизмом повышения прав в Ubuntu является утилита sudo. Эта утилита позволяет повысить права до уровня суперпользователя для выполняемой команды, при этом знать пароль суперпользователя не нужно, пользователь должен ввести собственный пароль. После чего утилита проверит, имеет ли данный пользователь право выполнять данную команду на данном хосте с правами суперпользователя и, в случае успешного прохождения проверок, выполнит ее.
Это важно! Основным отличием su от sudo служит то, что su позволяет сменить текущего пользователя на root, что требует активной записи суперпользователя в системе и знания пароля к ней, sudo позволяет повысить права для выполняемой команды без указания пароля суперпользователя, пользователь должен ввести свой собственный пароль, войти под root с этим учетными данными не получится.
Еще одно важное обстоятельство, при использовании конвейера или перенаправления с правами суперпользователя будет выполнена только первая часть команды, так например в конструкции:
с правами root будет выполнена только команда1. А команда
выдаст ошибку прав доступа так как запись в /etc/apt/sources.list будет происходить с правами обычного пользователя.
Чтобы выполнять сложные комбинации команд вы можете перейти в режим суперпользователя командой
что аналогично повышению прав командой su, однако пользовательское окружение от этого не изменится и в качестве домашнего будет использоваться каталог текущего пользователя, что удобно и безопасно. Каждый из администраторов будет иметь доступ только к своему домашнему каталогу.
Теперь самое время разобраться, кто имеет право использовать возможности sudo и в каком объеме. За настройки данной утилиты отвечает файл /etc/sudoers, несмотря на то, что это обычный конфигурационный файл для его редактирования настоятельно рекомендуется использовать команду:
Данная команда блокирует файл и осуществляет проверку синтаксиса, в противном случае вы рискуете из-за опечатки потерять административный доступ к ПК.
Синтаксис данного файла весьма прост. Например в самом конце файла содержится запись:
Это означает, что пользователи группы admin могут выполнять на любом хосте, от имени любого пользователя любую команду. Как мы можем легко убедиться с помощью команды groups в нашем случае пользователь andrey входит в группу admin, а пользователь petrov нет.
Но все достоинства данной утилиты заключаются в возможности гибко настроить параметры получения прав в каждом конкретном случае. Например:
Данная строка позволяет пользователю petrov выполнить любую команду на хосте ubuntu-lts от имени пользователя andrey. При указании команд следует указывать полный путь к ним, узнать его можно при помощи команды which
Например мы хотим разрешить пользователям petrov и sidorov выполнять выключение и перезагрузку компьютера, а также снимать задачи. При этом данные команды не должны требовать ввода пароля.
Еще одной приятной возможностью утилиты sudo является создание алиасов, так в нашем случае добавим в /etc/sudoers следующие строки:
которое позволит пользователям перечисленным в указанном алиасе выполнять на любом хосте от имени любого пользователя команды из приведенного алиаса без ввода пароля.
Кроме указанных двух, доступны алиасы и для имени хоста и пользователей от имени которых разрешено выполнять команды, например:
Приведенный набор записей позволит пользователям входящим в USERGROUP1 выполнять любые команды от имени пользователей www-data и www-developer на веб-серверах компании.
Напоследок рассмотрим, как же быть, если учетная запись root все таки нужна. Все просто, чтобы включить ее достаточно задать пароль:
Снова заблокировать учетную запись суперпользователя можно командой:
Помните, что все административные задачи в Ubuntu можно решать с использованием утилиты sudo, поэтому не включайте учетную запись root без реальной необходимости!
Как видим, Ubuntu имеет богатые возможности управления административными правами, что позволяет гибко распределять права между несколькими администраторами, а также давать возможность повышения прав некоторым пользователям, причем делать это эффективно и безопасно.
Читайте также: