Назад | Перейти на главную страницу

Правильный способ дать повышенные привилегии моно приложению?

У меня есть моно-приложение (на Ubuntu), которое отслеживает / var / log / messages и принимает USB-вставки, и если это устройство подключено к определенному порту, его необходимо разделить, отформатировать и смонтировать. Очевидно, для этого требуются права root. Я новичок в Linux, и мне интересно, какой «правильный» способ сделать это.

Лучше ли все время запускать мое приложение с правами root? Или лучше (или возможно) дать моему приложению разрешения размонтировать, расстались, mkfs, и монтировать и любой другой процесс только для root, который мне нужен?

Задний план:
После подключения некоторые файлы, запрошенные пользователем, будут загружены на диск. Каждый диск уникален, поэтому клонирование не сработает, и я буду поддерживать сотни дисков в неделю, поэтому мне нужно, чтобы это было максимально автоматизировано. Я понимаю, что это опасно, поэтому да, я поставлю на машину предупреждение о том, что все диски будут отформатированы. Я использую моно, потому что он хорошо подходит для более крупного приложения, написанного на C # .net.

На самом деле для этого вам не обязательно иметь права root. На самом деле, я настоятельно рекомендую не позволять ничему запускаться от имени root. Вот самый безопасный способ, который я бы посоветовал.

  1. Напишите однострочный сценарий оболочки, который выполняет chown на узле устройства пользователю, которое ваше моно-приложение работает как или chmod чтобы открыть доступ к миру или группе, достаточный для того, чтобы ваше приложение могло изменять устройство.
  2. Сохраните скрипт в /usr/local/bin принадлежит пользователю root и НЕ имеет права записи для пользователей.
  3. Добавить правило в sudoers это позволяет пользователю вашего моно-приложения запускать только что созданный сценарий.
  4. В вашем приложении после обнаружения устройства сначала запустите этот скрипт с помощью sudo чтобы устройство было доступно для чтения / записи вашему пользователю.
  5. Все свои действия проделайте на устройстве как пользователь!

Примечание. Не давайте приложению sudo доступ к chmod, chown, fdisk или любые другие подобные инструменты администрирования, только написанный вами защищенный одноцелевой скрипт, который открывает разрешения только на одном вашем устройстве.

Добавляя к ответу Калеба, для mount и umount вам не потребуются привилегии root для этого, пока вы настроили /etc/fstab с именами устройств и точками монтирования для каждого с "user, noauto" (в дополнение к любым другим параметрам, которые вам нужны. user дает обычным пользователям разрешение монтировать и размонтировать устройство, noauto сообщает процессу загрузки не пытаться монтировать их все при запуске ... fsck и dump столбцы также должны быть 0). Вам нужно будет создать одну запись и каталог для каждого устройства (например, /mnt/sda1 идти с /dev/sda1).

Если они будут отформатированы в FAT, вы можете полностью игнорировать монтирование. После использования mkfs.msdos для создания файловой системы используйте mtools для непосредственного редактирования файловой системы. Просматривая документацию mtools, есть хотя бы один временный файл (я нашел .mcwd), которые затрудняют одновременную работу с несколькими файловыми системами (для каждого процесса потребуется установить уникальный $MCWD переменная среды, указывающая на другое местоположение или другое имя файла для этого файла), поэтому обязательно внимательно прочитайте документацию.

В файловой системе ext2 открывается новый набор червей: владение пользователями и группами, а также права доступа к файлам. Самый простой способ обойти это - использовать скрипт для chown точка монтирования после монтирования файловой системы точно так же, как скрипт для загрузки файла устройства. Затем пользователь может записать файлы и использовать chmod для соответствующей установки разрешений. Проблема здесь в том, что у получателя диска может не быть подходящего пользователя, но если вы убедитесь, что «другие» биты чтения / записи / выполнения верны, и вы избегаете использования битов suid / sgid, это в основном косметическая проблема (если у них действительно нет пользователя, который соответствует вашему uid, и тогда этот человек сможет записывать на диск, если получатель не изменит разрешения немедленно).