Порт линукс без прав суперпользователя

Как дать Root права пользователю в Linux

Суперпользователь «root” — это король пользователей Linux / Unix. Наличие корневого доступа предоставляет полный и неограниченный доступ к дистрибутиву Linux.

В этой инструкции я покажу вам, как дать root права пользователю в системе Linux. Как правило, доступ на корневом уровне (root) используется в системном администрировании. Поэтому всегда больно давать root-доступ другим пользователям. Вы должны быть очень осторожны и должны забрать доступ, как только необходимость в этом отпадет.

Как дать Root права пользователю в Linux

Согласно разрешениям файловой системы Linux, root или суперпользователь имеет полные права на чтение (r), запись (w) и выполнение (x) любого файла. По умолчанию идентификатор пользователя root равен «0».

Я собираюсь создать двух пользователей, а именно user1 и user2. Затем я предоставлю root-правак пользователю «user1«.

Способ 1: Добавление в корневую группу с помощью usermod

Давайте посмотрим, как мы можем дать обычному пользователю root- права, добавив его в корневую группу.

# adduser user1
# adduser user2
# groupadd test

Это группы, которые есть в моей дистрибутиве Linux.

# groups
root bin daemon sys adm disk wheel

Я собираюсь добавить user1 в корневую группу следующим образом:

Приведенная ниже команда даст пользователю привилегию root

Способ 2: Добавление в корневую группу с помощью команды Useradd

Я добавил нового пользователя «user3» в корневую группу с помощью команды:

# useradd -m -G root user3
# groups user3
user3 : user3 root

useradd -c “Imitation Root” -d /home/root_user -m -k /etc/skel -s /bin/bash -u 0 -o -g root root_user

Способ 3: Редактирование файла /etc/passwd

Отредактируйте /etc/passwd для конкретного пользователя. Измените UID и GID пользователя на «0«. Это даст root права пользователю в linux.

Теперь пользователь temproot должен иметь привилегии root:

ВНИМАНИЕ: это не рекомендуемый метод предоставления корневого доступа (root-прав)

Способ 4: Дать права пользователя Sudo

Конфигурационный файл sudo — это файл /etc/sudoers, и вы можете отредактировать его с помощью команды visudo:

Использование visudo защищает от конфликтов и гарантирует использование правильного синтаксиса.

Чтобы предоставить полный доступ конкретным пользователям

Добавьте в файл запись, приведенную ниже:

Следовать этому методу не очень хорошая идея, потому что это позволяет и User1, и User2 использовать команду su для предоставления постоянных привилегий root. Таким образом пропуская функции ведения журнала команд sudo.

Предоставление доступа к определенным файлам одному конкретному пользователю

Эта запись позволяет User 1 и всем другим членам группы получить доступ ко всем программным файлам в каталогах /sbin и /usr/sbin, а также привилегию выполнения команды /usr/oracle/backup.pl…

User1, %operator ALL= /sbin/, / usr/sbin, /usr/oracle/backup.pl

Если у вас есть какие-либо вопросы или предложения по этой теме, оставьте комментарий.

Источник

Как зайти под root в Ubuntu

Политика дистрибутива Ubuntu нацелена на то, что все действия, требующих административных привилегий надо выполнять с помощью команды sudo. Использовать root пользователя как основного для новичков опасно, поскольку они ещё плохо ориентируются в системе и могут забыть, что они вошли как root и удалить что-то важное.

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

Как зайти под root в Ubuntu

По причинам, описанным выше для пользователя root пароль в Ubuntu не задан по умолчанию, поэтому вы не можете просто так войти от его имени с помощью в виртуальных консолях доступных по Ctrl+Alt+FN или с помощью утилиты su. Поскольку пароля нет, ввести его верно вы не сможете.

Но это всё очень просто обходится. Для того чтобы войти под пользователем root в терминале достаточно дописать sudo перед командой su:

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

Однако, если вы хотите авторизоваться от имени этого пользователя в виртуальной консоли или по SSH, то вам надо сначала задать для него пароль. Для этого выполните:

sudo passwd root

Затем введите два раза пароль. После этого пользователь root становится почти полноценным пользователем системы. Вы не сможете только войти под ним в графический интерфейс потому что на это действует ограничение самой оболочки Gnome, это очень плохая практика — запускать целую оболочку от имени root.

Но если вам всё же очень хочется, надо немного настроить правила PAM для GDM. Для этого откройте файл /etc/pam.d/gdm-password и закомментируйте там строчку:

sudo vi /etc/pam.d/gdm-password

# auth required pam_succeed_if.so user != root quiet_success

После этого вы сможете авторизоваться от имени root в менеджере входа. Просто кликните по пункту Нет в списке, а затем введите логин root:

Перед вами откроется оболочка, запущенная от имени суперпользователя:

Это очень небезопасно, потому что любая программа может делать с вашим компьютером всё, что захочет и никто её не остановит. Фактически, первые версии Windows тоже работали в таком режиме и поэтому они были очень уязвимы к вирусам.

Источник

Как открыть serial port без прав root

Сделал пробную программу на qt, которая работае с serial port. Программа окрывает порт если ее запустить через sudo. Без sudo просто информацию о портах выводит.

Как сделать что бы порты открывались без sudo обычный пользователь? Пробовал сделать что то типа: sudo chmod 777 serial не помогло. Таже проблемма и в программе putty.

Добавить пользователя в группу dialout.

Нужно пользователя добавить в группу, ток не помню какую, с телефона сижу и нет линукса род рукой. Если покажешь список групп то подскажу

Вот собственно и подсказали пока я писал 🙂

Добавил, перегрузился. Работает. Что это за группа за что она отвечает?

Уже точно не помню, в гуглях поищи, я так делал чтоб кассовые аппараты работали корректно и терминалы аваля

Что это за группа за что она отвечает?

Она ни за что не отвечает, но правила udev выставляют на сериальные устройства принадлежность к этой группе и

тоже помогло бы, если бы твоё «serial» соответствовало бы реальному устройству (не линк)

Группа определяется не по списку групп, а по правам на файл в /dev. В разных дистрибутивах может быть по разному.

Зря перегрузился. Надо было просто новую сессию начать.

Источник

Разрешить процесс без полномочий root связываться с портами 80 и 443?

Можно ли настроить параметр ядра, чтобы позволить программе пользовательского интерфейса связываться с портами 80 и 443?

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

Я бы предпочел попытаться выяснить, какой непривилегированный процесс прослушивает порт 80, а не пытаться удалить вредоносное ПО, проникшее с правами root.

4 ответа 4

Я не уверен, на что ссылаются другие ответы и комментарии здесь. Это возможно довольно легко. Существует два варианта, каждый из которых позволяет получить доступ к портам с низким номером без необходимости поднять процесс до уровня root:

Вариант 1. Используйте CAP_NET_BIND_SERVICE для предоставления доступа к порту с низким номером для процесса:

При этом вы можете предоставить постоянный доступ к конкретному двоичному файлу для привязки к портам с низким номером с помощью команды setcap :

Для получения дополнительной информации о части e/i/p см. cap_from_text .

После этого /path/to/binary сможет связываться с портами с низким номером. Обратите внимание, что вы должны использовать setcap для самого двоичного файла , а не символическую ссылку.

Вариант 2. Используйте authbind для предоставления одноразового доступа с более точным контролем пользователя / группы / порта:

Инструмент authbind (man-страница) существует именно для этого.

Установите authbind используя ваш любимый менеджер пакетов.

Настройте его для предоставления доступа к соответствующим портам, например, для разрешения 80 и 443 от всех пользователей и групп:

Теперь выполните вашу команду через authbind (при желании можно указать —deep или другие аргументы, см. Справочную страницу):

Есть и плюсы и минусы обоих вышеперечисленных. Вариант 1 предоставляет доверие к двоичному файлу, но не обеспечивает контроль доступа к каждому порту. Вариант 2 предоставляет доверие пользователю / группе и обеспечивает контроль доступа к каждому порту, но AFAIK поддерживает только IPv4.

Дейл Хэгглунд на месте. Так что я просто собираюсь сказать то же самое, но по-другому, с некоторыми особенностями и примерами. ☺

В мире Unix и Linux нужно сделать следующее:

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

Вы неправильно поняли, где находится высокий риск. Высокий риск заключается в чтении из сети и воздействии на то, что читается, а не в простых действиях по открытию сокета, привязке его к порту и вызову listen() . Это часть службы, которая осуществляет фактическое общение с высоким риском. Открываемые части, bind() и listen() и даже (в некоторой степени) accepts() часть не представляют высокого риска и могут выполняться под эгидой суперпользователя. Они не используют и не обрабатывают (за исключением исходных IP-адресов в случае accept() ) данные, которые находятся под контролем ненадежных незнакомцев в сети.

Есть много способов сделать это.

inetd

Как говорит Дейл Хагглунд, старый inetd «сетевого суперсервера» делает это. Учетная запись, под которой запускается сервисный процесс, является одним из столбцов в inetd.conf . Он не разделяет прослушивающую часть и часть удаления привилегий на две отдельные программы, маленькие и легко проверяемые, но он разделяет основной код службы на отдельную программу, exec() созданную в процессе службы, который порождается с помощью дескриптор открытого файла для сокета.

Сложность аудита — не такая уж большая проблема, поскольку нужно проверять только одну программу. Основная проблема inetd заключается не столько в аудите, сколько в том, что он не обеспечивает простого детального управления сервисом во время выполнения по сравнению с более поздними инструментами.

UCSPI-TCP и daemontools

Daniel J. Бернштейна UCSPI-TCP и DaemonTools пакеты были разработаны , чтобы сделать это в сочетании. В качестве альтернативы можно использовать практически эквивалентный набор инструментов Брюса Гюнтера на бис .

Программа для открытия дескриптора файла сокета и привязки к привилегированному локальному порту — tcpserver , из UCSPI-TCP. Это делает listen() и accept() .

Затем tcpserver запускает либо служебную программу, которая сама отбрасывает привилегии root (поскольку обслуживаемый протокол включает в себя запуск в качестве суперпользователя, а затем «вход в систему», как, например, в случае с демоном FTP или SSH), либо setuidgid который это отдельная небольшая и легко проверяемая программа, которая только отбрасывает привилегии и затем загружает их в цепочку непосредственно в служебную программу (ни одна из частей которой, таким образом, никогда не будет работать с привилегиями суперпользователя, как, например, в случае с qmail-smtpd ).

Таким образом, сценарий run службы может быть, например, таким (для dummyidentd для предоставления нулевой службы IDENT):

перекус

Мой пакет Nosh предназначен для этого. У него есть небольшая утилита setuidgid , как и у других. Одно небольшое отличие состоит в том, что его можно использовать со службами в стиле systemd «LISTEN_FDS», а также со службами UCSPI-TCP, поэтому традиционная программа tcpserver заменяется двумя отдельными программами: tcp-socket-listen и tcp-socket-accept .

Опять же, одноразовые утилиты порождают и загружают друг друга. Одна интересная особенность дизайна заключается в том, что можно отказаться от привилегий суперпользователя после listen() но даже до accept() . Вот скрипт run для qmail-smtpd который действительно делает именно это:

Программы, которые работают под эгидой суперпользователя — это небольшие сервисно-независимые инструменты загрузки fdmove , clearenv , envdir , softlimit , tcp-socket-listen и setuidgid . К моменту запуска sh , сокет открыт и привязан к порту smtp , и у процесса больше нет привилегий суперпользователя.

S6, S6-сети и Execline

Пакеты Laurent Bercot s6 и s6-network были разработаны для того, чтобы сделать это совместно. Команды структурно очень схожи с daemontools и UCSPI-TCP.

Сценарии run будут почти такими же, за исключением замены s6-tcpserver на tcpserver и s6-setuidgid на setuidgid . Тем не менее, можно также использовать набор инструментов execline М. Bercot в то же время.

Вот пример службы FTP, слегка измененной по сравнению с оригинальной Уэйн Маршалл, которая использует execline, s6, s6-network и программу сервера FTP из publicfile:

ipsvd

Ipsvd Gerrit Pape — это еще один набор инструментов, который работает по тем же принципам, что и ucspi-tcp и s6-network. На этот раз инструментами являются chpst и tcpsvd , но они делают то же самое, и код высокого риска, который выполняет чтение, обработку и запись вещей, отправленных по сети ненадежными клиентами, все еще находится в отдельной программе.

Вот пример М. Pape запуска fnord в сценарии run :

systemd

systemd , новая система управления службами и инициализации, которую можно найти в некоторых дистрибутивах Linux, предназначена для того, чтобы делать то, что может делать inetd . Тем не менее, он не использует набор небольших автономных программ. К сожалению, приходится проверять systemd полностью.

С помощью systemd создаются файлы конфигурации для определения сокета, который слушает systemd , и запускается служба, которая запускает systemd . Файл «модуля» службы имеет настройки, которые позволяют значительно контролировать процесс службы, в том числе от имени пользователя, с которым он работает.

Когда этот пользователь настроен как не суперпользователь, systemd выполняет всю работу по открытию сокета, привязке его к порту и вызову listen() (и, если требуется, accept() ) в процессе № 1 в качестве суперпользователя. и сервисный процесс, который он порождает, выполняется без привилегий суперпользователя.

Источник