Ресурсы процессов
Каждый процесс потребляет системные ресурсы, такие как память и процессорное время. Этот пост расскажет вам о системных вызовах, которые необходимы для получения подобной информацией о потребляемых ресурсах и контроля ряда ограничений.
Мы начнем с вызова getrusage(), который позволяет процессу следить за ресурсами, потребленными им или его потомками. Затем будут рассмотрены вызовы setrlimit() и getrlimit(), которые позволяют изменять и получать данные об установленных для вызывающего процесса ограничениях на различные ресурсы.
Ресурсы, использующиеся процессом:
Системный вызов getrusage() возвращает статистику, которая касается различных ресурсов системы, потребленных самим вызывающим процессом или всеми его потомками:
Данный вызов возвращает 0 при успешном завершении или –1, если произошла ошибка. Аргумент who обозначает процесс, для которого будет извлекаться информация о потреблении ресурсов. Он может принимать одно из следующих значений:
1. RUSAGE_SELF — возвращает сведения о вызывающем процессе.
2. RUSAGE_CHILDREN — возвращает сведения обо всех потомках вызывающего процесса.
3. RUSAGE_THREAD — возвращает сведения о вызывающем потоке (поддерживается только в Linux).
Аргумент res_usage представляет собой указатель на структуру типа rusage, поля которой заполняются в момент вызова:
Нужно помнить, что далеко не все поля структуры rusage заполняются вызовом getrusage(). Некоторые поля могут игнорироваться в Linux, но учитываться в других реализациях UNIX. В Linux они присутствуют на случай, если их реализуют в будущем - это позволит поддерживать бинарную совместимость с уже существующими приложениями.
Давайте на примере посмотрим, как можно получить "user/system" процессорное время, затраченное процессом на выполнение кода:
Ограничения на ресурсы для отдельных процессов:
Каждый процесс обладает набором параметров, с помощью которых можно ограничить объем тех или иных системных ресурсов, которые он может потребить. Сведения об ограничениях на ресурсы процесса можно получать и изменять с помощью системных вызовов getrlimit() и setrlimit():
Аргумент resource обозначает ограничение на ресурсы, которое нужно получить либо изменить. Рассмотрим несколько примеров возможных значений:
Аргумент rlim используется либо для возвращения существующих значений ограничения, либо для задания новых. Он представляет собой структуру, состоящую из двух полей:
Эти поля имеют целочисленный тип rlim_t и соответствуют двум ограничениям на один ресурс: мягкому (rlim_cur) и жесткому (rlim_max). Эти ограничения управляют тем, какой объем целевого ресурса может быть использован.
Мягкое ограничение регулирует количество ресурсов, которые могут быть использованы процессом. Процесс может использовать ресурсы в пределах этого значения. Жесткое ограничение является абсолютным максимумом, который нельзя превысить, даже при попытке изменить мягкое ограничение.
Linux++ | IT-Образование
Каждый процесс потребляет системные ресурсы, такие как память и процессорное время. Этот пост расскажет вам о системных вызовах, которые необходимы для получения подобной информацией о потребляемых ресурсах и контроля ряда ограничений.
Мы начнем с вызова getrusage(), который позволяет процессу следить за ресурсами, потребленными им или его потомками. Затем будут рассмотрены вызовы setrlimit() и getrlimit(), которые позволяют изменять и получать данные об установленных для вызывающего процесса ограничениях на различные ресурсы.
Ресурсы, использующиеся процессом:
Системный вызов getrusage() возвращает статистику, которая касается различных ресурсов системы, потребленных самим вызывающим процессом или всеми его потомками:
#include <sys/resource.h>
int getrusage(int who, struct rusage *res_usage);
Данный вызов возвращает 0 при успешном завершении или –1, если произошла ошибка. Аргумент who обозначает процесс, для которого будет извлекаться информация о потреблении ресурсов. Он может принимать одно из следующих значений:
1. RUSAGE_SELF — возвращает сведения о вызывающем процессе.
2. RUSAGE_CHILDREN — возвращает сведения обо всех потомках вызывающего процесса.
3. RUSAGE_THREAD — возвращает сведения о вызывающем потоке (поддерживается только в Linux).
Аргумент res_usage представляет собой указатель на структуру типа rusage, поля которой заполняются в момент вызова:
struct rusage {
/* Процессорное время, потребленное пользователем */
struct timeval ru_utime;
/* Процессорное время, потребленное системой */
struct timeval ru_stime;
/* Размер страницы памяти, выделенной процессу */
long ru_maxrss;
...
}
Нужно помнить, что далеко не все поля структуры rusage заполняются вызовом getrusage(). Некоторые поля могут игнорироваться в Linux, но учитываться в других реализациях UNIX. В Linux они присутствуют на случай, если их реализуют в будущем - это позволит поддерживать бинарную совместимость с уже существующими приложениями.
Давайте на примере посмотрим, как можно получить "user/system" процессорное время, затраченное процессом на выполнение кода:
#include <stdio.h>
#include <sys/resource.h>
#include <sys/time.h>
#include <unistd.h>
void main() {
/* Some Work... */
struct rusage usage;
if (getrusage(RUSAGE_SELF, &usage) == 0) {
printf("User CPU time: %ld.%06ld seconds\n",
usage.ru_utime.tv_sec, usage.ru_utime.tv_usec);
printf("System CPU time: %ld.%06ld seconds\n",
usage.ru_stime.tv_sec, usage.ru_stime.tv_usec);
}
}
Ограничения на ресурсы для отдельных процессов:
Каждый процесс обладает набором параметров, с помощью которых можно ограничить объем тех или иных системных ресурсов, которые он может потребить. Сведения об ограничениях на ресурсы процесса можно получать и изменять с помощью системных вызовов getrlimit() и setrlimit():
int getrlimit(int resource, struct rlimit *rlim);
int setrlimit(int resource, const struct rlimit *rlim);
Аргумент resource обозначает ограничение на ресурсы, которое нужно получить либо изменить. Рассмотрим несколько примеров возможных значений:
RLIMIT_AS Размер виртуальной памяти процесса (байты)
RLIMIT_CORE Размер дампа памяти (байты)
RLIMIT_CPU Процессорное время (секунды)
...
Аргумент rlim используется либо для возвращения существующих значений ограничения, либо для задания новых. Он представляет собой структуру, состоящую из двух полей:
struct rlimit {
rlim_t rlim_cur;
rlim_t rlim_max;
};
Эти поля имеют целочисленный тип rlim_t и соответствуют двум ограничениям на один ресурс: мягкому (rlim_cur) и жесткому (rlim_max). Эти ограничения управляют тем, какой объем целевого ресурса может быть использован.
Мягкое ограничение регулирует количество ресурсов, которые могут быть использованы процессом. Процесс может использовать ресурсы в пределах этого значения. Жесткое ограничение является абсолютным максимумом, который нельзя превысить, даже при попытке изменить мягкое ограничение.
Linux++ | IT-Образование
1👍21❤6❤🔥5🔥2
Демоны в Linux
Демон - это процесс, обладающий длинным жизненным циклом. Часто демоны создаются на этапе загрузки системы и работают до момента ее выключения. Выполняется они в фоновом режиме, не имеют контролирующего терминала и обычно не привязаны к конкретной пользовательской сессии.
Примеры системных демонов
У каждого системного демона есть своя микроцель существования. Одни контролируют сетевые соединения, другие отвечают за взаимодействие между приложениями по системе dbus. Примерами популярных демонов являются:
1) cron — демон, который выполняет команды в запланированное время;
2) sshd — демон, который отвечает за обработку SSH-подключений;
3) httpd — демон HTTP-сервера (Apache), который обслуживает веб-страницы;
Вы можете и сами "поймать" демонов через различные утилиты: ps, top, pstree. Базовыми отличительными параметрами таких процессов являются имя, которое заканчивается на 'd', родительский процесс init и отсутствующий терминал:
Дополнительно хочется отметить, что процессам-демонам присуща особенность, которая гарантирует, что ядро не сможет генерировать для них никаких сигналов, связанных с терминалом (SIGINT, SIGTSTP и SIGHUP).
Создание демона
Глобально существует 2 типа демонов: "SysV Daemons" и "New-Style Daemons". Первый тип является традиционным и преимущественно использовался до появления systemd. Второй, в свою очередь, опирается на инфраструктуру systemd и является сервисом.
Сейчас не будем вдаваться в принцип работы сервисов и рассмотрим инициализацию каноничного SysV демона. Для того, чтобы стать демоном, программа должна выполнить следующие шаги:
1. Сделать вызов fork(), после которого родитель завершается, а потомок продолжает работать. Это нужно для отделения демона от терминала, из которого он был запущен. В результате, процесс становится потомком для init:
2. Дочерний процесс вызывает setsid(), чтобы начать новую сессию, стать ее лидером и разорвать любые связи с контролирующим терминалом:
3. Проигнорировать сигнал SIGHUP для того, чтобы не завершиться при закрытии терминала, внутри которого был воспроизведен запуск:
4. Повторно выполнить fork(). Этот шаг иногда выполняется для предотвращения возможности захвата вновь созданного демона новым управляющим терминалом.
5. Очистить атрибут umask, чтобы файлы и каталоги, созданные демоном, имели запрашиваемые права доступа, указанные в вызовах open() и mkdir():
6. Поменять текущий рабочий каталог процесса (обычно на корневой). Это необходимо для исключения блокировки файловой системы и возможности, в случае необходимости, сделать для нее unmount:
7. Закрыть все открытые файловые дескрипторы, которые демон унаследовал от своего родителя. Поскольку демон потерял свой контролирующий терминал и работает в фоновом режиме, ему больше не нужно хранить дескрипторы с номерами 0, 1 и 2, их тоже закрываем:
8. Переоткрыть дескрипторы STDIN, STDOUT, STDERR и перенаправить стандартные потоки в виртуальное устройство "/dev/null". Данный шаг необходим по нескольким причинам.
Во-первых, вновь открытые файлы неизбежно возьмут себе минимально доступный порядковый номер (0, 1, 2 ...), что может привести к нежелательным записям со стороны функций, которые работают с этими дескрипторами.
Во-вторых, данное действие позволяет избежать ошибок при вызове библиотечных функций, которые выполняют операции ввода/вывода с этими дескрипторами:
9. Запустить основной цикл, в котором демон будет выполнять свою работу:
Linux++ | IT-Образование
Демон - это процесс, обладающий длинным жизненным циклом. Часто демоны создаются на этапе загрузки системы и работают до момента ее выключения. Выполняется они в фоновом режиме, не имеют контролирующего терминала и обычно не привязаны к конкретной пользовательской сессии.
Примеры системных демонов
У каждого системного демона есть своя микроцель существования. Одни контролируют сетевые соединения, другие отвечают за взаимодействие между приложениями по системе dbus. Примерами популярных демонов являются:
1) cron — демон, который выполняет команды в запланированное время;
2) sshd — демон, который отвечает за обработку SSH-подключений;
3) httpd — демон HTTP-сервера (Apache), который обслуживает веб-страницы;
Вы можете и сами "поймать" демонов через различные утилиты: ps, top, pstree. Базовыми отличительными параметрами таких процессов являются имя, которое заканчивается на 'd', родительский процесс init и отсутствующий терминал:
$ ps -o pid,ppid,cmd
PID PPID CMD
1239 1 /usr/lib/snapd/snapd
1250 1 /usr/libexec/udisks2/udisksd
Дополнительно хочется отметить, что процессам-демонам присуща особенность, которая гарантирует, что ядро не сможет генерировать для них никаких сигналов, связанных с терминалом (SIGINT, SIGTSTP и SIGHUP).
Создание демона
Глобально существует 2 типа демонов: "SysV Daemons" и "New-Style Daemons". Первый тип является традиционным и преимущественно использовался до появления systemd. Второй, в свою очередь, опирается на инфраструктуру systemd и является сервисом.
Сейчас не будем вдаваться в принцип работы сервисов и рассмотрим инициализацию каноничного SysV демона. Для того, чтобы стать демоном, программа должна выполнить следующие шаги:
1. Сделать вызов fork(), после которого родитель завершается, а потомок продолжает работать. Это нужно для отделения демона от терминала, из которого он был запущен. В результате, процесс становится потомком для init:
pid_t pid = fork();
if (pid < 0)
exit(EXIT_FAILURE);
if (pid > 0)
exit(EXIT_SUCCESS);
2. Дочерний процесс вызывает setsid(), чтобы начать новую сессию, стать ее лидером и разорвать любые связи с контролирующим терминалом:
if (setsid() < 0)
exit(EXIT_FAILURE);
3. Проигнорировать сигнал SIGHUP для того, чтобы не завершиться при закрытии терминала, внутри которого был воспроизведен запуск:
signal(SIGHUP, SIG_IGN);
4. Повторно выполнить fork(). Этот шаг иногда выполняется для предотвращения возможности захвата вновь созданного демона новым управляющим терминалом.
5. Очистить атрибут umask, чтобы файлы и каталоги, созданные демоном, имели запрашиваемые права доступа, указанные в вызовах open() и mkdir():
umask(0);
6. Поменять текущий рабочий каталог процесса (обычно на корневой). Это необходимо для исключения блокировки файловой системы и возможности, в случае необходимости, сделать для нее unmount:
chdir("/");
7. Закрыть все открытые файловые дескрипторы, которые демон унаследовал от своего родителя. Поскольку демон потерял свой контролирующий терминал и работает в фоновом режиме, ему больше не нужно хранить дескрипторы с номерами 0, 1 и 2, их тоже закрываем:
for (int x = sysconf(_SC_OPEN_MAX); x>=0; x--)
close (x);
8. Переоткрыть дескрипторы STDIN, STDOUT, STDERR и перенаправить стандартные потоки в виртуальное устройство "/dev/null". Данный шаг необходим по нескольким причинам.
Во-первых, вновь открытые файлы неизбежно возьмут себе минимально доступный порядковый номер (0, 1, 2 ...), что может привести к нежелательным записям со стороны функций, которые работают с этими дескрипторами.
Во-вторых, данное действие позволяет избежать ошибок при вызове библиотечных функций, которые выполняют операции ввода/вывода с этими дескрипторами:
int fd0 = open("/dev/null", O_RDWR);
int fd1 = dup(0);
int fd2 = dup(0);
9. Запустить основной цикл, в котором демон будет выполнять свою работу:
while (1) {
}
Linux++ | IT-Образование
1👍34❤🔥12❤7🔥7👾2😈1
Идентификаторы процессов: пользователи и группы [1]
У каждого процесса есть набор, связанных с ним числовых идентификаторов пользователей (UID) и групп (GID). В число этих идентификаторов входят:
1) реальный (real) ID пользователя и группы;
2) действующий (effective) ID пользователя и группы;
3) сохранённый ID пользователя (set-user-ID) и группы (set-group-ID);
4) характерный для Linux пользовательский и групповой ID файловой системы;
5) дополнительные идентификаторы групп (supplementary group);
Реальный идентификатор пользователя и группы (RUID)
Реальные идентификаторы определяют пользователя и группу, которым принадлежит процесс. При входе в систему, оболочка получает свои ID пользователя и группы из полей файла "/etc/passwd". Каждый новый процесс наследует данные идентификаторы у своего родительского процесса:
Действующий идентификатор пользователя и группы (EUID)
В большинстве реализаций UNIX действующие UID и GID используются для определения полномочий, которыми наделен процесс, при его попытке выполнения различных операций (в том числе, системных вызовов).
Эти ID используются ядром для определения прав, которые будет иметь процесс при доступе к общим ресурсам, таким как: очереди сообщений, общая память, объекты межпроцессного взаимодействия (IPC) и семафоры.
В большинстве систем UNIX эти ID также определяют права доступа к файлам (в Linux для этой задачи используются ID файловой системы).
Процесс, чей действующий идентификатор пользователя имеет значение 0, называется привилегированным и принадлежит пользователю с именем root (имеет все полномочия суперпользователя). Некоторые системные вызовы могут быть выполнены только привилегированными процессами.
ID действующего пользователя и группы процесса можно получить с помощью вызовов geteuid и getegid.
Проводя сравнение между EUID и RUID можно сказать, что RUID обозначает пользователя, который владеет процессом, EUID является параметром, на который смотрит ядро ОС для того, чтобы разрешить вам выполнить действие либо отклонить запрос:
Также, важно помнить, что значение EUID может быть изменено и некоторые программы, такие как sudo, используют это для того, чтобы выполнять ряд привилегированных операций.
Сохранённые set-user-ID и set-group-ID (SUID)
Эти ID используются в программах с set-user-ID и set-group-ID битами для сохранения копии соответствующих EUID. Бит SUID можно опознать по букве 's', заменяющей обычный бит выполнения 'x'. Это говорит нам о том, что файл будет выполняться с правами владельца, а не пользователя, который его запускает:
Когда set-user-ID-программа запускается (загружается в память процесса с помощью команды exec()), ядро устанавливает для действующего EUID точно такое же значение, что и у пользовательского UID исполняемого файла:
После запуска, EUID пользователя будет скопирован в SUID. Идентификаторы процесса будут проставлены следующим образом: RUID=1000, ЕUID=0, SUID=0.
Программа с set-user-ID может повышать и понижать права, переключая свой ID действующего пользователя (EUID) между значениями RUID и SUID. Это полезно в случаях, когда, например, привилегированному процессу нужно выполнить непривилегированную задачу.
Такое переключение производится с помощью вызовов seteuid, setreuid или setresuid. Программа с set-group-ID выполняет аналогичные задачи с помощью setegid, setregid или setresgid.
Сохранённые set-user-ID и set-group-ID процесса можно получить с помощью getresuid и getresgid соответственно.
Linux++ | IT-Образование
У каждого процесса есть набор, связанных с ним числовых идентификаторов пользователей (UID) и групп (GID). В число этих идентификаторов входят:
1) реальный (real) ID пользователя и группы;
2) действующий (effective) ID пользователя и группы;
3) сохранённый ID пользователя (set-user-ID) и группы (set-group-ID);
4) характерный для Linux пользовательский и групповой ID файловой системы;
5) дополнительные идентификаторы групп (supplementary group);
Реальный идентификатор пользователя и группы (RUID)
Реальные идентификаторы определяют пользователя и группу, которым принадлежит процесс. При входе в систему, оболочка получает свои ID пользователя и группы из полей файла "/etc/passwd". Каждый новый процесс наследует данные идентификаторы у своего родительского процесса:
$ echo $UID
1000
$ grep $LOGNAME /etc/passwd
hiko:x:1000:1000:hiko:/home/hiko:/bin/bash
$ stat -c "%u %g" /proc/$pid/
1000 1000
Действующий идентификатор пользователя и группы (EUID)
В большинстве реализаций UNIX действующие UID и GID используются для определения полномочий, которыми наделен процесс, при его попытке выполнения различных операций (в том числе, системных вызовов).
Эти ID используются ядром для определения прав, которые будет иметь процесс при доступе к общим ресурсам, таким как: очереди сообщений, общая память, объекты межпроцессного взаимодействия (IPC) и семафоры.
В большинстве систем UNIX эти ID также определяют права доступа к файлам (в Linux для этой задачи используются ID файловой системы).
Процесс, чей действующий идентификатор пользователя имеет значение 0, называется привилегированным и принадлежит пользователю с именем root (имеет все полномочия суперпользователя). Некоторые системные вызовы могут быть выполнены только привилегированными процессами.
ID действующего пользователя и группы процесса можно получить с помощью вызовов geteuid и getegid.
Проводя сравнение между EUID и RUID можно сказать, что RUID обозначает пользователя, который владеет процессом, EUID является параметром, на который смотрит ядро ОС для того, чтобы разрешить вам выполнить действие либо отклонить запрос:
$ ps -eo pid,euid,ruid | grep 2254
2254 0 0
Также, важно помнить, что значение EUID может быть изменено и некоторые программы, такие как sudo, используют это для того, чтобы выполнять ряд привилегированных операций.
Сохранённые set-user-ID и set-group-ID (SUID)
Эти ID используются в программах с set-user-ID и set-group-ID битами для сохранения копии соответствующих EUID. Бит SUID можно опознать по букве 's', заменяющей обычный бит выполнения 'x'. Это говорит нам о том, что файл будет выполняться с правами владельца, а не пользователя, который его запускает:
$ stat -c "%A %a %n" /usr/bin/passwd
-rwsr-xr-x 4755 /usr/bin/passwd
Когда set-user-ID-программа запускается (загружается в память процесса с помощью команды exec()), ядро устанавливает для действующего EUID точно такое же значение, что и у пользовательского UID исполняемого файла:
$ su
# chown root app
# chmod u+s app
# ls -l app
-rwsr-xr-x 1 root users
После запуска, EUID пользователя будет скопирован в SUID. Идентификаторы процесса будут проставлены следующим образом: RUID=1000, ЕUID=0, SUID=0.
Программа с set-user-ID может повышать и понижать права, переключая свой ID действующего пользователя (EUID) между значениями RUID и SUID. Это полезно в случаях, когда, например, привилегированному процессу нужно выполнить непривилегированную задачу.
Такое переключение производится с помощью вызовов seteuid, setreuid или setresuid. Программа с set-group-ID выполняет аналогичные задачи с помощью setegid, setregid или setresgid.
Сохранённые set-user-ID и set-group-ID процесса можно получить с помощью getresuid и getresgid соответственно.
Linux++ | IT-Образование
1👍24🔥5❤2❤🔥2🥰1
Идентификаторы процессов: пользователи и группы [2]
И так, в прошлый раз мы посмотрели на первые 3 базовых идентификатора: RUID, EUID и SUID. Сегодня пойдем дальше и добьем последние 2:
1) ID пользователя и группы файловой системы (FSUID);
2) ID дополнительных групп (supplementary group);
ID пользователя и группы файловой системы (FSUID)
В Linux для определения прав доступа к файлам, применяются не пользовательские и групповые EUID, а соответствующие ID файловой системы (FSUID). Они используются в этом качестве наряду с идентификаторами дополнительных групп, описанных ниже.
Обычно идентификаторы файловой системы имеют те же значения, что и соответствующие действующие собраты. Более того, каждый раз при изменении EUID ядро также автоматически изменяет и FSUID, присваивая ему аналогичное значение:
Однако, никто не запрещает вам изменить ID файловой системы и сделать его отличным от действующих ID. Реализовать это можно через вызовы setfsuid и setfsgid:
А зачем в Linux вообще предоставляются идентификаторы файловой системы и при каких обстоятельствах нам могут понадобиться разные значения для EUID и FSUID?
Причины главным образом имеют исторические корни. Идентификаторы файловой системы впервые появились в Linux 1.2. В этой версии ядра один процесс мог отправлять сигнал другому, лишь если EUID отправителя совпадал с RUID или EUID целевого процесса.
Это повлияло на некоторые программы, например на программу сервера Linux NFS (Network File System), которой нужна была возможность доступа к файлам, как будто у нее есть действующие идентификаторы соответствующих клиентских процессов.
Но, если бы NFS-сервер изменял свой действующий идентификатор пользователя, он стал бы уязвим от сигналов непривилегированных пользовательских процессов.
Для предотвращения этой возможности были придуманы отдельные FSUID. Оставляя неизмененными свои действующие идентификаторы, но изменяя идентификаторы файловой системы, NFS-сервер может выдавать себя за другого пользователя с целью обращения к файлам без уязвимости от сигналов пользовательских процессов.
Начиная с версии ядра 2.0, приняты правила относительно разрешений на отправку сигналов, в результате чего, наличие FSUID утратило свою актуальность. В наше время ID файловой системы считаются некой экзотикой и, как правило, совпадают по значениям с EUID.
ID дополнительных групп (supplementary group)
В ранних реализациях unix, процесс мог принадлежать только к одной группе, прописанной в "/etc/passwd". Сейчас же можно принадлежать сразу к нескольким.
Новый процесс наследует эти идентификаторы от своего родительского процесса. Оболочка входа в систему получает свои дополнительные идентификаторы групп из файла групп системы "/etc/group":
Как уже ранее отмечалось, эти идентификаторы используются в совокупности с EUID и FSUID для определения полномочий по доступу к файлам, IPC-объектам и другим системным ресурсам.
Процесс может получить список ID дополнительных групп с помощь getgroups, и изменить этот список с помощью setgroups:
Linux++ | IT-Образование
И так, в прошлый раз мы посмотрели на первые 3 базовых идентификатора: RUID, EUID и SUID. Сегодня пойдем дальше и добьем последние 2:
1) ID пользователя и группы файловой системы (FSUID);
2) ID дополнительных групп (supplementary group);
ID пользователя и группы файловой системы (FSUID)
В Linux для определения прав доступа к файлам, применяются не пользовательские и групповые EUID, а соответствующие ID файловой системы (FSUID). Они используются в этом качестве наряду с идентификаторами дополнительных групп, описанных ниже.
Обычно идентификаторы файловой системы имеют те же значения, что и соответствующие действующие собраты. Более того, каждый раз при изменении EUID ядро также автоматически изменяет и FSUID, присваивая ему аналогичное значение:
$ ps -eo pid,uid,euid,suid,fsuid,comm
PID UID EUID SUID FSUID COMMAND
1 0 0 0 0 systemd
Однако, никто не запрещает вам изменить ID файловой системы и сделать его отличным от действующих ID. Реализовать это можно через вызовы setfsuid и setfsgid:
#include <sys/fsuid.h>
int setfsuid(uid_t fsuid);
int setfsgid(gid_t fsgid);
А зачем в Linux вообще предоставляются идентификаторы файловой системы и при каких обстоятельствах нам могут понадобиться разные значения для EUID и FSUID?
Причины главным образом имеют исторические корни. Идентификаторы файловой системы впервые появились в Linux 1.2. В этой версии ядра один процесс мог отправлять сигнал другому, лишь если EUID отправителя совпадал с RUID или EUID целевого процесса.
Это повлияло на некоторые программы, например на программу сервера Linux NFS (Network File System), которой нужна была возможность доступа к файлам, как будто у нее есть действующие идентификаторы соответствующих клиентских процессов.
Но, если бы NFS-сервер изменял свой действующий идентификатор пользователя, он стал бы уязвим от сигналов непривилегированных пользовательских процессов.
Для предотвращения этой возможности были придуманы отдельные FSUID. Оставляя неизмененными свои действующие идентификаторы, но изменяя идентификаторы файловой системы, NFS-сервер может выдавать себя за другого пользователя с целью обращения к файлам без уязвимости от сигналов пользовательских процессов.
Начиная с версии ядра 2.0, приняты правила относительно разрешений на отправку сигналов, в результате чего, наличие FSUID утратило свою актуальность. В наше время ID файловой системы считаются некой экзотикой и, как правило, совпадают по значениям с EUID.
ID дополнительных групп (supplementary group)
В ранних реализациях unix, процесс мог принадлежать только к одной группе, прописанной в "/etc/passwd". Сейчас же можно принадлежать сразу к нескольким.
Новый процесс наследует эти идентификаторы от своего родительского процесса. Оболочка входа в систему получает свои дополнительные идентификаторы групп из файла групп системы "/etc/group":
$ cat /etc/group | grep xodefender
adm:x:4:syslog,xodefender
cdrom:x:24:xodefender
sudo:x:27:xodefender
dip:x:30:xodefender
video:x:44:xodefender
Как уже ранее отмечалось, эти идентификаторы используются в совокупности с EUID и FSUID для определения полномочий по доступу к файлам, IPC-объектам и другим системным ресурсам.
Процесс может получить список ID дополнительных групп с помощь getgroups, и изменить этот список с помощью setgroups:
#include <unistd.h>
int getgroups(int size, gid_t list[]);
#include <grp.h>
int setgroups(size_t size, const gid_t *_Nullable list);
Linux++ | IT-Образование
1👍17❤3🔥3👾2
Valve продолжает пушить Linux
Разработчики из компании Valve представили проект frog-protocols, в рамках которого планируется развивать дополнительный набор протоколов для Wayland, дополняющих протоколы из набора wayland-protocols.
Расширения из wayland-protocols необходимы для создания композитных серверов и пользовательских окружений.
Создание отдельного набора протоколов к Wayland объясняется слишком медленным и буксующим в бесконечных обсуждениях процессом принятия новых протоколов в wayland-protocols, который может затягиваться на месяцы и годы.
В проекте frog-protocols протоколы намерены доводить до пользователей как можно быстрее.
По мнению создателей инициативы, многие пользователи продолжают работать в окружениях на базе протокола X11 из-за отсутствия необходимой функциональности, которая может быть предоставлена уже сейчас, но по тем или иным причинам её продвижение блокируется.
Готовые пакеты с первой версией frog-protocols уже приняты в репозитории Arch Linux, Fedora 41 и Fedora 40, а также находятся на стадии включения в состав openSUSE.
Первыми двумя Wayland-протоколами, включёнными в состав frog-protocols, стали frog-fifo-v1 и frog-color-management-v1.
Протокол frog-color-management добавляет расширения для управления цветом, предоставляющих возможности для работы с HDR в играх.
Протокол frog-fifo отмечается как очень примитивный по своей сути, но предоставляющий важные возможности, решающие проблемы с высокой нагрузкой на GPU при использовании VSync, снижением производительности и зависанием приложений при перекрытии их окон другими окнами при включённом FIFO/VSync.
Код с реализацией протокола frog-fifo передан для включения в основной состав Mesa.
Изменения, добавляющие поддержку протокола, также подготовлены для композитного менеджера KWin, который развивается проектом KDE.
Реализация уже опробована в работе и входит в состав SteamOS и композитного сервера Gamescope.
Предлагаемое изменение сводится к обеспечению корректной работы Wayland-клиента с FIFO благодаря переходу к ожиданию завершения вертикальной развёртки (vblank) вместо использования callback-вызовов при каждой готовности отобразить новый кадр.
В ходе обсуждения, один из разработчиков wlroots, выразил сомнение в целесообразности добавления протоколов, развиваемых в обход основанной на достижении консенсуса модели разработки wayland-protocols или не учитывающих интересы Wayland-сообщества.
Пьер-Лу Гриффе из компании Valve ответил, что текущей модели разработки wayland-protocols не хватает быстрого цикла продвижения экспериментальных протоколов, который позволил бы проводить эксперименты, сразу получать обратную связь от пользователей и учитывать её при дальнейшей разработке.
Linux++ | IT-Образование
Разработчики из компании Valve представили проект frog-protocols, в рамках которого планируется развивать дополнительный набор протоколов для Wayland, дополняющих протоколы из набора wayland-protocols.
Расширения из wayland-protocols необходимы для создания композитных серверов и пользовательских окружений.
Создание отдельного набора протоколов к Wayland объясняется слишком медленным и буксующим в бесконечных обсуждениях процессом принятия новых протоколов в wayland-protocols, который может затягиваться на месяцы и годы.
В проекте frog-protocols протоколы намерены доводить до пользователей как можно быстрее.
По мнению создателей инициативы, многие пользователи продолжают работать в окружениях на базе протокола X11 из-за отсутствия необходимой функциональности, которая может быть предоставлена уже сейчас, но по тем или иным причинам её продвижение блокируется.
Готовые пакеты с первой версией frog-protocols уже приняты в репозитории Arch Linux, Fedora 41 и Fedora 40, а также находятся на стадии включения в состав openSUSE.
Первыми двумя Wayland-протоколами, включёнными в состав frog-protocols, стали frog-fifo-v1 и frog-color-management-v1.
Протокол frog-color-management добавляет расширения для управления цветом, предоставляющих возможности для работы с HDR в играх.
Протокол frog-fifo отмечается как очень примитивный по своей сути, но предоставляющий важные возможности, решающие проблемы с высокой нагрузкой на GPU при использовании VSync, снижением производительности и зависанием приложений при перекрытии их окон другими окнами при включённом FIFO/VSync.
Код с реализацией протокола frog-fifo передан для включения в основной состав Mesa.
Изменения, добавляющие поддержку протокола, также подготовлены для композитного менеджера KWin, который развивается проектом KDE.
Реализация уже опробована в работе и входит в состав SteamOS и композитного сервера Gamescope.
Предлагаемое изменение сводится к обеспечению корректной работы Wayland-клиента с FIFO благодаря переходу к ожиданию завершения вертикальной развёртки (vblank) вместо использования callback-вызовов при каждой готовности отобразить новый кадр.
В ходе обсуждения, один из разработчиков wlroots, выразил сомнение в целесообразности добавления протоколов, развиваемых в обход основанной на достижении консенсуса модели разработки wayland-protocols или не учитывающих интересы Wayland-сообщества.
Пьер-Лу Гриффе из компании Valve ответил, что текущей модели разработки wayland-protocols не хватает быстрого цикла продвижения экспериментальных протоколов, который позволил бы проводить эксперименты, сразу получать обратную связь от пользователей и учитывать её при дальнейшей разработке.
Linux++ | IT-Образование
👍21🔥6❤🔥3👎1
Файл групп: /etc/group
В недавнем посте мы кратко затронули системный файл "/etc/group". Сегодня мы чуть подробнее рассмотрим его практическую ценность и структуру содержимого. Го!
Пользователей для различных административных целей, в частности для управления доступом к файлам и другим системным ресурсам, полезно свести в группы. Это нужно по той причине, что не всем юзерам системы доступны для чтения, записи и выполнения все существующие ресурсы.
Мы ведь не можем просто так взять и поменять содержимое какого-нибудь системного конфига из директории etc. Например dhcpcd.conf. Нам, для того, чтобы воспроизвести запись, нужно выполнить рад действий:
1) проверить группу, к которой принадлежит файл;
2) проверить права, которыми располагает группа;
Тут мы видим следующее: файл принадлежит пользователю root и его одноименной группе. Также, права для пользователя, позволяют ему выполнять запись и чтение. Членам группы позволено только читать содержимое файла, т.к. указан только 1 бит "r".
Давайте, для начала, поменяем файлу группу так, чтобы конкретный пользователь смог к нему обратиться:
Вот, хорошо, теперь мы, от пользователя xodefender можем, хотя бы, прочитать файл:
Можем ли мы записать что-то... Пока нет. Для этого нам нужно добавить бит "w" на запись для группы:
Хорошо, теперь с правами все норм, можем воспроизвести запись в файл от пользователя xodefender:
Ага, а если мы хотим выполнять данные операции от пулла доверенных пользователей... В таком случае, нам нужно создать для них группу и присвоить ее целевому файлу. Давайте действовать поступательно и начнем с создания группы:
Список групп с соответствующей информацией можно найти в файле "/etc/group", который содержит по одной строке на каждую группу. Каждая строка, как показано в следующем примере, состоит из четырех полей, отделенных друг от друга двоеточиями:
Рассмотрим эти поля в порядке следования:
1) имя группы - легко читаемый символьный идентификатор, соответствующий числовому;
2) зашифрованный пароль группы, который, в действительности, хранится в теневом файле групп "/etc/gshadow";
3) числовой идентификатор группы (GID);
4) список пользователей, которые входят в группу;
Далее, давайте добавим доверенных пользователей в группу:
Теперь нужно повторить процесс из начала поста - изменить группу файла и выставить необходимые права:
Все, пожалуйста, пользователи xodefender и test_1 (участники группы admins) могут читать файл и записывать в него информацию:
Linux++ | IT-Образование
В недавнем посте мы кратко затронули системный файл "/etc/group". Сегодня мы чуть подробнее рассмотрим его практическую ценность и структуру содержимого. Го!
Пользователей для различных административных целей, в частности для управления доступом к файлам и другим системным ресурсам, полезно свести в группы. Это нужно по той причине, что не всем юзерам системы доступны для чтения, записи и выполнения все существующие ресурсы.
Мы ведь не можем просто так взять и поменять содержимое какого-нибудь системного конфига из директории etc. Например dhcpcd.conf. Нам, для того, чтобы воспроизвести запись, нужно выполнить рад действий:
1) проверить группу, к которой принадлежит файл;
2) проверить права, которыми располагает группа;
$ ls -l | grep dhcp
-rw-r--r-- 1 root root 1429 Mar 31 11:48 dhcpcd.conf
Тут мы видим следующее: файл принадлежит пользователю root и его одноименной группе. Также, права для пользователя, позволяют ему выполнять запись и чтение. Членам группы позволено только читать содержимое файла, т.к. указан только 1 бит "r".
Давайте, для начала, поменяем файлу группу так, чтобы конкретный пользователь смог к нему обратиться:
$ sudo chgrp xodefender dhcpcd.conf
$ ls -l | grep dhcp
-rw-r----- 1 root xodefender 1437 Sep 27 11:02 dhcpcd.conf
Вот, хорошо, теперь мы, от пользователя xodefender можем, хотя бы, прочитать файл:
$ cat dhcpcd.conf
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
...
Можем ли мы записать что-то... Пока нет. Для этого нам нужно добавить бит "w" на запись для группы:
$ sudo chmod g+w dhcpcd.conf
$ ls -l | grep dhcp
-rw-rw---- 1 root xodefender 1437 Sep 27 11:05 dhcpcd.conf
Хорошо, теперь с правами все норм, можем воспроизвести запись в файл от пользователя xodefender:
$ echo "Some useful data" >> dhcpcd.conf
Ага, а если мы хотим выполнять данные операции от пулла доверенных пользователей... В таком случае, нам нужно создать для них группу и присвоить ее целевому файлу. Давайте действовать поступательно и начнем с создания группы:
$ sudo groupadd admins
Список групп с соответствующей информацией можно найти в файле "/etc/group", который содержит по одной строке на каждую группу. Каждая строка, как показано в следующем примере, состоит из четырех полей, отделенных друг от друга двоеточиями:
$ cat /etc/group
admins:x:1002:
jambit:x:106:claus,felli,frank,harti,markus
Рассмотрим эти поля в порядке следования:
1) имя группы - легко читаемый символьный идентификатор, соответствующий числовому;
2) зашифрованный пароль группы, который, в действительности, хранится в теневом файле групп "/etc/gshadow";
3) числовой идентификатор группы (GID);
4) список пользователей, которые входят в группу;
Далее, давайте добавим доверенных пользователей в группу:
$ sudo usermod --append --groups admins xodefender
$ sudo usermod --append --groups admins test_1
$ cat /etc/group | grep admins
admins:x:1002:xodefender,test_1
Теперь нужно повторить процесс из начала поста - изменить группу файла и выставить необходимые права:
$ sudo chgrp admins dhcpcd.conf
$ sudo chmod g+rw dhcpcd.conf
Все, пожалуйста, пользователи xodefender и test_1 (участники группы admins) могут читать файл и записывать в него информацию:
$ su test_1
$ cat dhcpcd.conf
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
...
Linux++ | IT-Образование
1👍22🔥2❤🔥1🌭1
Топ каналов по Linux и C++
Сегодняшний пост немного выделится и массы и будет посвящен моим рекомендациям различного медиаконтента по изучению Linux, C и C++.
Тут не будет воды и каких-то "левых" каналов - только то, что лично мной было пройдено и проверено.
Если что, комментарии для вас всегда открыты, можете, с высоты личного опыта, дополнить данный список.
C/C++
1. The Cherno (английский) - ютуб канал С++ разработчика, который ранее работал в EA SPORTS над корпоративным движком Frostbite.
Теперь уже автор пишет свой игровой движок и, к сожалению, не так много времени уделяет обучающему контену, но, в свое время, был находкой для новичков, решивших изучать C++ и OpenGL.
2. Илья Мещерин - публичный спикер, лектор и практикующий С++ разработчик. На сколько я знаю, Илья работал в таких компаниях, как Яндекс, ВК и Ядро. Контент, который им производится, подойдет не только начинающим, но и довольно опытным программистам.
От его лица вы вряд ли найдете разборы библиотек и фреймворков, КРИТИЧЕСКИ необходимых для трудоустройства. По его видео можно хорошо отточить C++ и STL, чего и будет достаточно для определенных целей (например, подготовке к собесам).
Лекции выходят от канала ФПМИ. Также, пулл уроков от 2020 года можно найти в плейлисте.
3. ambushedraccoon - отечественный блогер/интервьюер. Его контент основан на проведении junior/middle C++ собесов. Если хотите проработать ответы на самые актуальные вопросы рынка, рекомендую.
4. Jacob Sorber (английский) - разработчик, специализирующийся на embedded и IOT технологиях. Автор затрагивает как совсем базовые, так и довольно глубокие темы, касающиеся языков программирования C/С++, Linux OS и Computer Science.
Linux
1. NetworkChuck (английский) - канал сетевого инженера, который, помимо всего прочего, научит вас основам работы с Linux.
Да, сейчас уже все переходит в развлекательный формат, т.к. надо фармить просмотры, однако все еще можно "выловить" немало полезного материала.
Так, например, плейлисты по подсетям, основам bash и базовому администрированию.
В чем автор силен, так это в динамической подаче материала. Если вам наскучили унылые лекции, можете обратить внимание на NetworkChuck.
2. Learn Linux TV (английский) - канал системного инженера. Основные хайлайты: bash, разборы системных команд, изучение текстового редактора vim.
Linux++ | IT-Образование
Сегодняшний пост немного выделится и массы и будет посвящен моим рекомендациям различного медиаконтента по изучению Linux, C и C++.
Тут не будет воды и каких-то "левых" каналов - только то, что лично мной было пройдено и проверено.
Если что, комментарии для вас всегда открыты, можете, с высоты личного опыта, дополнить данный список.
C/C++
1. The Cherno (английский) - ютуб канал С++ разработчика, который ранее работал в EA SPORTS над корпоративным движком Frostbite.
Теперь уже автор пишет свой игровой движок и, к сожалению, не так много времени уделяет обучающему контену, но, в свое время, был находкой для новичков, решивших изучать C++ и OpenGL.
2. Илья Мещерин - публичный спикер, лектор и практикующий С++ разработчик. На сколько я знаю, Илья работал в таких компаниях, как Яндекс, ВК и Ядро. Контент, который им производится, подойдет не только начинающим, но и довольно опытным программистам.
От его лица вы вряд ли найдете разборы библиотек и фреймворков, КРИТИЧЕСКИ необходимых для трудоустройства. По его видео можно хорошо отточить C++ и STL, чего и будет достаточно для определенных целей (например, подготовке к собесам).
Лекции выходят от канала ФПМИ. Также, пулл уроков от 2020 года можно найти в плейлисте.
3. ambushedraccoon - отечественный блогер/интервьюер. Его контент основан на проведении junior/middle C++ собесов. Если хотите проработать ответы на самые актуальные вопросы рынка, рекомендую.
4. Jacob Sorber (английский) - разработчик, специализирующийся на embedded и IOT технологиях. Автор затрагивает как совсем базовые, так и довольно глубокие темы, касающиеся языков программирования C/С++, Linux OS и Computer Science.
Linux
1. NetworkChuck (английский) - канал сетевого инженера, который, помимо всего прочего, научит вас основам работы с Linux.
Да, сейчас уже все переходит в развлекательный формат, т.к. надо фармить просмотры, однако все еще можно "выловить" немало полезного материала.
Так, например, плейлисты по подсетям, основам bash и базовому администрированию.
В чем автор силен, так это в динамической подаче материала. Если вам наскучили унылые лекции, можете обратить внимание на NetworkChuck.
2. Learn Linux TV (английский) - канал системного инженера. Основные хайлайты: bash, разборы системных команд, изучение текстового редактора vim.
Linux++ | IT-Образование
👍11❤7❤🔥2🌭1
Файлы паролей: passwd и shadow
В linux для аутентификации пользователя и хранения информации о нем используются 2 файла /etc/passwd и /etc/shadow. Давайте рассмотрим назначения каждого из них.
Файл /etc/passwd
В системном файле паролей /etc/passwd содержится по одной строке для каждой учетной записи пользователя. Каждая строка состоит из семи полей:
Рассмотрим эти поля по порядку следования:
1. Имя для входа в систему. Это уникальное имя, которое пользователь должен вводить при входе в систему - легко читаемый символьный идентификатор пользователя, соответствующий числовому (UID).
2. Зашифрованный пароль. В этом поле содержится 13-символьный зашифрованный пароль пользователя. Поскольку этот файл используется многими утилитами типа ls, чтобы отобразить владельца файла и другие подобные сведения, он должен быть открыт на чтение для всех, что, конечно, дает отличный шанс хакерам.
По этой причине, в настоящее время, поле пароля в /etc/passwd содержит букву 'x', чтобы обозначить, что пароль был назначен и сохранен в теневом файле /etc/shadow.
Если поле является пустым, значит, для регистрации под этой учетной записью пароль не нужен.
3. Числовой идентификатор пользователя (UID). Если поле хранит значение 0, то пользователь с данной учетной записью - привилегированный (суперпользователь).
Как правило, имеется только одна такая учетная запись, у которой в качестве имени для входа в систему используется слово root.
4. Числовой идентификатор первой из групп, в которую входит пользователь (GID). Дальнейшая принадлежность к группам этого пользователя определена в системном файле групп.
5. Комментарий. Это поле содержит текст, описывающий пользователя. Такой текст выводится различными программами, например finger.
6. Домашний каталог. Исходный каталог, в который пользователь попадает после входа в систему. Содержимое этого поля становится значением переменной среды HOME.
7. Оболочка входа в систему. Это программа, которой передается управление после входа пользователя в систему. Обычно это одна из оболочек, например bash, но может быть и любая другая программа.
Если это поле является пустым, то в качестве исходной, применяется оболочка /bin/sh. Содержимое поля становится значением для переменной среды SHELL.
Теневой файл /etc/shadow
Теневой файл паролей /etc/shadow был разработан, как средство противостояния хакерским атакам.
Замысел заключается в том, что вся неконфиденциальная информация о пользователе находится в открытом, доступном для чтения файле passwd, а зашифрованные пароли хранятся в теневом файле, доступном для чтения только программам с особыми привилегиями.
Файл /etc/shadow хранит данные о пользователе в формате. Как и в файле passwd, каждое поле в файле shadow отделяется двоеточием:
1. Имя пользователя (до 8 символов). Совпадает по значению с /etc/passwd.
2. Зашифрованный пароль (13 символов). Пустая запись '::' показывает, что для входа пароль не нужен (обычно идея плохая).
3. Количество дней, начиная с 1 января 1970, когда пароль был сменен в последний раз.
4. Число дней до смены пароля (0, если он может быть сменен всегда).
5. Число дней, после которых пароль должен быть сменен (99999, если пользователь может не менять пароль фактически никогда).
6. Число дней, в течение которых пользователь получает предупреждения о необходимости пароль сменить (7 для полной недели).
7. Число дней после окончания действия пароля, когда еще можно работать. Если пароль не сменить, после данного срока он выдохнется, и аккаунт будет заблокирован.
8. Число дней, начиная с 1 января 1970, после которых пароль будет заблокирован.
9. Зарезервировано для возможного будущего использования.
Linux++ | IT-Образование
В linux для аутентификации пользователя и хранения информации о нем используются 2 файла /etc/passwd и /etc/shadow. Давайте рассмотрим назначения каждого из них.
Файл /etc/passwd
В системном файле паролей /etc/passwd содержится по одной строке для каждой учетной записи пользователя. Каждая строка состоит из семи полей:
mtk:x:1000:100:Michael Kerrisk:/home/mtk:/bin/bash
Рассмотрим эти поля по порядку следования:
1. Имя для входа в систему. Это уникальное имя, которое пользователь должен вводить при входе в систему - легко читаемый символьный идентификатор пользователя, соответствующий числовому (UID).
2. Зашифрованный пароль. В этом поле содержится 13-символьный зашифрованный пароль пользователя. Поскольку этот файл используется многими утилитами типа ls, чтобы отобразить владельца файла и другие подобные сведения, он должен быть открыт на чтение для всех, что, конечно, дает отличный шанс хакерам.
По этой причине, в настоящее время, поле пароля в /etc/passwd содержит букву 'x', чтобы обозначить, что пароль был назначен и сохранен в теневом файле /etc/shadow.
Если поле является пустым, значит, для регистрации под этой учетной записью пароль не нужен.
3. Числовой идентификатор пользователя (UID). Если поле хранит значение 0, то пользователь с данной учетной записью - привилегированный (суперпользователь).
Как правило, имеется только одна такая учетная запись, у которой в качестве имени для входа в систему используется слово root.
4. Числовой идентификатор первой из групп, в которую входит пользователь (GID). Дальнейшая принадлежность к группам этого пользователя определена в системном файле групп.
5. Комментарий. Это поле содержит текст, описывающий пользователя. Такой текст выводится различными программами, например finger.
6. Домашний каталог. Исходный каталог, в который пользователь попадает после входа в систему. Содержимое этого поля становится значением переменной среды HOME.
$ echo $HOME
/home/xodefender
7. Оболочка входа в систему. Это программа, которой передается управление после входа пользователя в систему. Обычно это одна из оболочек, например bash, но может быть и любая другая программа.
Если это поле является пустым, то в качестве исходной, применяется оболочка /bin/sh. Содержимое поля становится значением для переменной среды SHELL.
$ echo $SHELL
/bin/bash
Теневой файл /etc/shadow
Теневой файл паролей /etc/shadow был разработан, как средство противостояния хакерским атакам.
Замысел заключается в том, что вся неконфиденциальная информация о пользователе находится в открытом, доступном для чтения файле passwd, а зашифрованные пароли хранятся в теневом файле, доступном для чтения только программам с особыми привилегиями.
Файл /etc/shadow хранит данные о пользователе в формате. Как и в файле passwd, каждое поле в файле shadow отделяется двоеточием:
smithj:Ep6mckrOLChF.:10063:0:99999:7:::
1. Имя пользователя (до 8 символов). Совпадает по значению с /etc/passwd.
2. Зашифрованный пароль (13 символов). Пустая запись '::' показывает, что для входа пароль не нужен (обычно идея плохая).
3. Количество дней, начиная с 1 января 1970, когда пароль был сменен в последний раз.
4. Число дней до смены пароля (0, если он может быть сменен всегда).
5. Число дней, после которых пароль должен быть сменен (99999, если пользователь может не менять пароль фактически никогда).
6. Число дней, в течение которых пользователь получает предупреждения о необходимости пароль сменить (7 для полной недели).
7. Число дней после окончания действия пароля, когда еще можно работать. Если пароль не сменить, после данного срока он выдохнется, и аккаунт будет заблокирован.
8. Число дней, начиная с 1 января 1970, после которых пароль будет заблокирован.
9. Зарезервировано для возможного будущего использования.
Linux++ | IT-Образование
🔥19👍17❤🔥2❤1🌭1💯1
Копаемся c архивами в Linux
В Linux существует множество консольных утилит для работы с архивами и сжатыми файлами.
Нередко в работе бывают случаи, когда GUI под рукой не оказывается (при работе через ssh) и приходится выкручиваться для того, чтобы прочитать ".tar.gz" или ".zip" архивчик.
команды zip и unzip
zip используется для сжатия и архивирования файлов по одноименному алгоритму.
Через параметр ARCHIVE команда принимает имя архива, в который надо добавить файлы. После этого параметру FILES передается набор архивируемых файлов/каталогов:
Команда unzip, наоборот, позволяет распаковать архив и в общем случае имеет следующий формат:
команды tar, gzip и gunzip
gzip (GNU zip) - архиватор файлов с расширением ".gz".
Данная команда не умеет упаковывать несколько файлов в один архив и используется для поштучного сжатия. Для каждого переданного экземпляра создается спрессованный ".gz" собрат:
gunzip - распаковщик архивов ".gz". Команда является эквивалентом для "gzip -d":
Для упаковки нескольких файлов, их сначала необходимо архивировать в один через утилиту tar и уже потом сжать результат командой gzip.
tar - это утилита, которая используется для объединения нескольких файлов и директорий в один архив.
Сама по себе команда не сжимает файлы, а просто сохраняет их в один ".tar" файл.
Давайте рассмотрим комбо:
Таким образом, сжатые архивы обычно имеют двойное расширение ".tar.gz" или сокращённое ".tgz".
Для того, чтобы распаковать архив, можно использовать флаг "-x":
команда zcat
Команда zcat похожа, по сути, на cat и используется для вывода содержимого сжатых файлов формата ".gz" без необходимости их предварительной распаковки:
Linux++ | IT-Образование
В Linux существует множество консольных утилит для работы с архивами и сжатыми файлами.
Нередко в работе бывают случаи, когда GUI под рукой не оказывается (при работе через ssh) и приходится выкручиваться для того, чтобы прочитать ".tar.gz" или ".zip" архивчик.
команды zip и unzip
zip используется для сжатия и архивирования файлов по одноименному алгоритму.
Через параметр ARCHIVE команда принимает имя архива, в который надо добавить файлы. После этого параметру FILES передается набор архивируемых файлов/каталогов:
zip [OPTIONS] ARCHIVE FILES
$ zip myfiles.zip book.pdf image.png
Команда unzip, наоборот, позволяет распаковать архив и в общем случае имеет следующий формат:
unzip [OPTIONS] ARCHIVE
$ unzip myfiles.zip
команды tar, gzip и gunzip
gzip (GNU zip) - архиватор файлов с расширением ".gz".
Данная команда не умеет упаковывать несколько файлов в один архив и используется для поштучного сжатия. Для каждого переданного экземпляра создается спрессованный ".gz" собрат:
# -k : сохраняет изначальный файл
$ gzip -k file1.txt file2.txt
gunzip - распаковщик архивов ".gz". Команда является эквивалентом для "gzip -d":
$ gunzip file.txt.gz
$ gzip -d file.txt.gz
Для упаковки нескольких файлов, их сначала необходимо архивировать в один через утилиту tar и уже потом сжать результат командой gzip.
tar - это утилита, которая используется для объединения нескольких файлов и директорий в один архив.
Сама по себе команда не сжимает файлы, а просто сохраняет их в один ".tar" файл.
Давайте рассмотрим комбо:
# -c : Создать новый архив
# -f : Указать имя создаваемого архива
$ tar -cf archive.tar file.txt
$ gzip archive.tar
Таким образом, сжатые архивы обычно имеют двойное расширение ".tar.gz" или сокращённое ".tgz".
Для того, чтобы распаковать архив, можно использовать флаг "-x":
$ tar -xf archive.tar
команда zcat
Команда zcat похожа, по сути, на cat и используется для вывода содержимого сжатых файлов формата ".gz" без необходимости их предварительной распаковки:
$ zcat file.txt.gz
Hello world
Linux++ | IT-Образование
👍19🔥3❤🔥1🌭1
Valve начинает сотрудничество с Arch Linux
Разработчики дистрибутива Arch Linux объявили о переходе к прямому сотрудничеству с компанией Valve, развивающей операционную систему SteamOS, основанную на Arch Linux.
Компания Valve поможет в сопровождении сборочной инфраструктуры и поддержании анклава для заверения компонентов дистрибутива цифровыми подписями.
Valve предоставит дополнительные ресурсы, которые позволят развивать отмеченные области, не ограничиваясь свободным временем добровольцев.
Ожидается, что сотрудничество с Valve ускорит решение некоторых актуальных проблем дистрибутива, ускорит разработку и позволит быстрее реализовать планы.
Для всех, инициируемых Valve значительных изменений, будут создаваться RFC и публиковаться issue в GitLab, что позволит добиться прозрачности и даст возможность сообществу контролировать ход работы.
Linux++ | IT-Образование
Разработчики дистрибутива Arch Linux объявили о переходе к прямому сотрудничеству с компанией Valve, развивающей операционную систему SteamOS, основанную на Arch Linux.
Компания Valve поможет в сопровождении сборочной инфраструктуры и поддержании анклава для заверения компонентов дистрибутива цифровыми подписями.
Valve предоставит дополнительные ресурсы, которые позволят развивать отмеченные области, не ограничиваясь свободным временем добровольцев.
Ожидается, что сотрудничество с Valve ускорит решение некоторых актуальных проблем дистрибутива, ускорит разработку и позволит быстрее реализовать планы.
Для всех, инициируемых Valve значительных изменений, будут создаваться RFC и публиковаться issue в GitLab, что позволит добиться прозрачности и даст возможность сообществу контролировать ход работы.
Linux++ | IT-Образование
🔥33👍14❤1
Процессы и программы: переменные окружения
У каждого процесса есть, связанный с ним строковый массив, который называется списком переменных среды (окружения). Каждая из его строк является элементом вида имя=значение.
Таким образом, среда представляет собой набор пар имя — значение, которые могут применяться для хранения произвольной информации.
Когда создается новый процесс, он наследует копию среды своего родителя. Это простая, но часто используемая форма межпроцессного взаимодействия (IPC), когда среда предоставляет способ переноса информации от родительского процесса к дочернему.
Результат переноса информации от родительского процесса к дочернему является односторонним и однократным. После создания потомка, любой последующий экземпляр может изменить свою собственную среду, и эти изменения будут незаметны извне.
Некоторые библиотечные функции позволяют изменять свое поведение путем установки переменных среды. Это дает возможность пользователю управлять поведением приложения без изменения кода или его перекомпоновки с использованием соответствующей зависимости.
Один из классических примеров - переменная среды LD_LIBRARY_PATH, которую мы ранее затрагивали. Когда программа использует динамические библиотеки, загрузчик ищет их в системных каталогах lib или /usr/lib. Однако с помощью LD_LIBRARY_PATH можно указать альтернативные пути поиска:
Определение переменных окружения
В большинстве оболочек значение может быть добавлено к среде с помощью команды export:
В примере выше, первой командой создается переменная оболочки, которая, без явного экспорта, не будет унаследована дочерним процессом. Второй вызов определяет переменную для окружения и помещает ее в среду процесса.
В оболочках bash и Korn можно воспользоваться следующей записью:
Показанные выше команды навсегда добавляют значение к окружению оболочки, после чего это окружение наследуется всеми, создаваемыми оболочкой дочерними процессами. Переменная может быть в любой момент удалена командой unset:
В оболочке Bourne shell и ее потомках (bash и Korn) для добавления значений к окружению выполняемой программы, может использоваться такой синтаксис:
Определение будет добавлено к среде только того дочернего процесса, который выполняет указанную программу. Текущий список переменных среды выводится командой printenv:
Список переменных среды любого процесса можно изучить, обратившись к характерному для Linux "/proc/PID/environ":
Обращение к среде из программы
Из программы на языке C, список переменных среды может быть доступен с помощью глобальной переменной environ. Как и argv, переменная environ содержит список указателей на строки, заканчивающиеся нулевыми байтами. Cам список заканчивается значением NULL:
Альтернативный метод обращения к списку переменных среды заключается в объявлении для функции main() третьего аргумента:
Отдельные значения из среды процесса извлекаются с помощью getenv():
Linux++ | IT-Образование
У каждого процесса есть, связанный с ним строковый массив, который называется списком переменных среды (окружения). Каждая из его строк является элементом вида имя=значение.
Таким образом, среда представляет собой набор пар имя — значение, которые могут применяться для хранения произвольной информации.
Когда создается новый процесс, он наследует копию среды своего родителя. Это простая, но часто используемая форма межпроцессного взаимодействия (IPC), когда среда предоставляет способ переноса информации от родительского процесса к дочернему.
Результат переноса информации от родительского процесса к дочернему является односторонним и однократным. После создания потомка, любой последующий экземпляр может изменить свою собственную среду, и эти изменения будут незаметны извне.
Некоторые библиотечные функции позволяют изменять свое поведение путем установки переменных среды. Это дает возможность пользователю управлять поведением приложения без изменения кода или его перекомпоновки с использованием соответствующей зависимости.
Один из классических примеров - переменная среды LD_LIBRARY_PATH, которую мы ранее затрагивали. Когда программа использует динамические библиотеки, загрузчик ищет их в системных каталогах lib или /usr/lib. Однако с помощью LD_LIBRARY_PATH можно указать альтернативные пути поиска:
$ LD_LIBRARY_PATH=/usr/local/lib ./myapp
Определение переменных окружения
В большинстве оболочек значение может быть добавлено к среде с помощью команды export:
$ SHELL=/bin/bash
$ export SHELL
В примере выше, первой командой создается переменная оболочки, которая, без явного экспорта, не будет унаследована дочерним процессом. Второй вызов определяет переменную для окружения и помещает ее в среду процесса.
В оболочках bash и Korn можно воспользоваться следующей записью:
$ export SHELL=/bin/bash
Показанные выше команды навсегда добавляют значение к окружению оболочки, после чего это окружение наследуется всеми, создаваемыми оболочкой дочерними процессами. Переменная может быть в любой момент удалена командой unset:
$ unset VARIABLE_NAME
В оболочке Bourne shell и ее потомках (bash и Korn) для добавления значений к окружению выполняемой программы, может использоваться такой синтаксис:
$ NAME=value program
Определение будет добавлено к среде только того дочернего процесса, который выполняет указанную программу. Текущий список переменных среды выводится командой printenv:
$ printenv
LOGNAME=mtk
SHELL=/bin/bash
HOME=/home/mtk
PATH=/usr/local/bin:/usr/bin:/bin:.
TERM=xterm
Список переменных среды любого процесса можно изучить, обратившись к характерному для Linux "/proc/PID/environ":
$ cd /proc/2953
$ cat environ
HOME=/home/xodefenderLANG=en_US.UTF-8LOGNAME=xodefender
Обращение к среде из программы
Из программы на языке C, список переменных среды может быть доступен с помощью глобальной переменной environ. Как и argv, переменная environ содержит список указателей на строки, заканчивающиеся нулевыми байтами. Cам список заканчивается значением NULL:
#include <stdio.h>
extern char **environ;
int
main(int argc, char *argv[])
{
char **list;
for (list = environ; *list != NULL; list++) {
puts(*list);
}
exit(EXIT_SUCCESS);
}
Альтернативный метод обращения к списку переменных среды заключается в объявлении для функции main() третьего аргумента:
int main(int argc, char *argv[], char *envp[])
Отдельные значения из среды процесса извлекаются с помощью getenv():
#include <stdlib.h>
char *getenv(const char *name);
Linux++ | IT-Образование
👍24🔥4👌1
Хочется больше, используй stat
Иногда возникает необходимость в получении дополнительной информации, которую не предоставляет команда ls.
Вдруг, интересно посмотреть на количество блоков с данными или узнать номер ресурса в таблице inode... Полный обзор статуса файла/каталога в файловой системе выдает именно команда stat:
В результе вызова команды stat будет показано почти все, что можно узнать о целевом ресурсе, ввплоть до старшего и младшего номеров устройства, на котором хранится файл.
Давайте кратко рассмотрим часть информации, которую выдает stat:
1) File: /var/log/syslog - путь до ресурса, включая название;
2) Size: 15731467 - размер ресурса в байтах;
3) Blocks: 30736 - количесвто, выделенных под информацию блоков, расположенных на носителе;
4) Inode: 527906 - номер ресурса в таблице inode;
5) Links: 1 - количество жестких ссылок на ресурс;
Команда может анализировать и отдельные файловые системы. Для того, чтобы получить пулл данных, нам будет нужен флаг '-f':
Если указать в качестве аргумента файл, то информация выведется о файловой системе, на которой он расположен.
Также, если вам требуется через ссылку получить инфу о файле, на который она указывает, можно задействовать флаг '-L', смотрим:
Linux++ | IT-Образование
Иногда возникает необходимость в получении дополнительной информации, которую не предоставляет команда ls.
Вдруг, интересно посмотреть на количество блоков с данными или узнать номер ресурса в таблице inode... Полный обзор статуса файла/каталога в файловой системе выдает именно команда stat:
$ stat some_file
В результе вызова команды stat будет показано почти все, что можно узнать о целевом ресурсе, ввплоть до старшего и младшего номеров устройства, на котором хранится файл.
Давайте кратко рассмотрим часть информации, которую выдает stat:
1) File: /var/log/syslog - путь до ресурса, включая название;
2) Size: 15731467 - размер ресурса в байтах;
3) Blocks: 30736 - количесвто, выделенных под информацию блоков, расположенных на носителе;
4) Inode: 527906 - номер ресурса в таблице inode;
5) Links: 1 - количество жестких ссылок на ресурс;
Команда может анализировать и отдельные файловые системы. Для того, чтобы получить пулл данных, нам будет нужен флаг '-f':
$ stat -f /
Если указать в качестве аргумента файл, то информация выведется о файловой системе, на которой он расположен.
Также, если вам требуется через ссылку получить инфу о файле, на который она указывает, можно задействовать флаг '-L', смотрим:
$ stat -L link_to_file
Linux++ | IT-Образование
🔥19👍14❤3
Графический стек Linux
В мучительных потугах проходит изучение необъятного граф. стека нашей любимой ОС.
Около года назад чувствовал себя тут поувереннее, пришло время смахнуть пыль со скрытых уголков подсознания и поднять архивы.
Нашел как-то на хабре норм статью, которая является переводом трудов бывшего разработчика Gnome Shell.
В своей работе автор описывает суть основных компонентов стека (DIX, DDX, DRM, DRI, Xorg, GLX...) и рассказывает, как оно там все рисуется на низком уровне и какие библиотеки для этого используются.
Вообще, эти знания являются довольно базовыми и могут быть полезны как для написания софта, так и для решения ряда проблем с графикой, особенно релевантных для X11.
Тут, если копнуть, есть ряд прослоек драйверов на разных уровнях, некоторые могут работать некорректно конкретно с вашим чипсетом, поэтому не всегда будет правильным решением все сразу спихивать на mesa и бежать в issues.
Возможно, ваш кейс требует поставить intel вместо modesetting либо проработать конфиги)
Настоятельно рекомендую, по возможности, читать оригинал, т.к. в переводе есть шанс немного "недопонять" автора в технических разъяснениях.
Linux++ | IT-Образование
В мучительных потугах проходит изучение необъятного граф. стека нашей любимой ОС.
Около года назад чувствовал себя тут поувереннее, пришло время смахнуть пыль со скрытых уголков подсознания и поднять архивы.
Нашел как-то на хабре норм статью, которая является переводом трудов бывшего разработчика Gnome Shell.
В своей работе автор описывает суть основных компонентов стека (DIX, DDX, DRM, DRI, Xorg, GLX...) и рассказывает, как оно там все рисуется на низком уровне и какие библиотеки для этого используются.
Вообще, эти знания являются довольно базовыми и могут быть полезны как для написания софта, так и для решения ряда проблем с графикой, особенно релевантных для X11.
Тут, если копнуть, есть ряд прослоек драйверов на разных уровнях, некоторые могут работать некорректно конкретно с вашим чипсетом, поэтому не всегда будет правильным решением все сразу спихивать на mesa и бежать в issues.
Возможно, ваш кейс требует поставить intel вместо modesetting либо проработать конфиги)
Настоятельно рекомендую, по возможности, читать оригинал, т.к. в переводе есть шанс немного "недопонять" автора в технических разъяснениях.
Linux++ | IT-Образование
🔥25👍6🤯2
Такие похожие, но такие разные
Говоря простыми словами, chown определяет, кому принадлежит файл, а chmod указывает биты доступа, которые трактуют правила о том, кому и что с файлом или каталогом вообще можно делать.
Через команду chown мы можем указать владельца ресурса и группу, которая будет иметь к нему доступ:
Утилита chmod, в свою очередь, определяет "rwx" биты для ресурса. Как мы знаем, бит 'r' разрешает чтение файла, 'w' отвечает за его изменение и 'x' за выполнение.
Мы можем сказать "Так, вот пользователь может все, а группа только читать файл!".
Для реализации нужно выполнить:
Также, вы наверняка видели использвание chmod с числовым аргументом, например "777".
Таким способом тоже можно выдавать права. Каждое число относится к отдельной касте (пользователь, группа, остальные).
Грубо говоря, число 7 описывает доступ "по всем фронтам" rwx. Если мы захотим добиться результата команды выше, только с числовым аргументом, нам потребуется:
1) для пользователя: 4 (чтение) + 2 (запись) + 1 (выполнение) = 7;
2) для группы: 4 (чтение) = 4;
3) для кого-то еще: ничего = 0;
Linux++ | IT-Образование
Говоря простыми словами, chown определяет, кому принадлежит файл, а chmod указывает биты доступа, которые трактуют правила о том, кому и что с файлом или каталогом вообще можно делать.
Через команду chown мы можем указать владельца ресурса и группу, которая будет иметь к нему доступ:
$ chown hero:admins file
Утилита chmod, в свою очередь, определяет "rwx" биты для ресурса. Как мы знаем, бит 'r' разрешает чтение файла, 'w' отвечает за его изменение и 'x' за выполнение.
Мы можем сказать "Так, вот пользователь может все, а группа только читать файл!".
Для реализации нужно выполнить:
$ chmod u=rwx,g=r ./file
Также, вы наверняка видели использвание chmod с числовым аргументом, например "777".
Таким способом тоже можно выдавать права. Каждое число относится к отдельной касте (пользователь, группа, остальные).
Грубо говоря, число 7 описывает доступ "по всем фронтам" rwx. Если мы захотим добиться результата команды выше, только с числовым аргументом, нам потребуется:
$ chmod 740 ./file
1) для пользователя: 4 (чтение) + 2 (запись) + 1 (выполнение) = 7;
2) для группы: 4 (чтение) = 4;
3) для кого-то еще: ничего = 0;
Linux++ | IT-Образование
👍28🔥15❤4
Что нового в kde-plasma 6.2?
После четырёх месяцев разработки опубликован релиз среды рабочего стола KDE Plasma 6.2.
Честно говоря, как не нравилось мне kde, так ничего и не меняется с релизами, хотя по функционалу окружение очень неплохое)
Ну ладно, давайте посмотрим на основные изменения, которые пришли с обновой:
1. Добавлена возможность сборки KWin только с поддержкой сеанса Wayland.
2. Добавлена возможность использовать, встроенные в монитор данные цветового профиля.
3. В виджет управления яркостью экрана добавлены ползунки для настройки каждого отдельного монитора.
4. Добавлено всплывающее уведомление с запросом пожертвований, которое будет выводиться только раз в год.
5. Реализована звуковая индикация подключения и отключения монитора.
6. При использовании Wayland реализована поддержка механизма "sticky keys" для людей c нарушенной мелкой моторикой.
Со списком всех изменений с приложенными изображениями, можно ознакомиться на русскоязычном ресурсе.
Есть тут фанаты KDE? Давайте проведем оценку:
🔥 — топлю за GNOME
👍 — кайфую от KDE
Linux++ | IT-Образование
После четырёх месяцев разработки опубликован релиз среды рабочего стола KDE Plasma 6.2.
Честно говоря, как не нравилось мне kde, так ничего и не меняется с релизами, хотя по функционалу окружение очень неплохое)
Ну ладно, давайте посмотрим на основные изменения, которые пришли с обновой:
1. Добавлена возможность сборки KWin только с поддержкой сеанса Wayland.
2. Добавлена возможность использовать, встроенные в монитор данные цветового профиля.
3. В виджет управления яркостью экрана добавлены ползунки для настройки каждого отдельного монитора.
4. Добавлено всплывающее уведомление с запросом пожертвований, которое будет выводиться только раз в год.
5. Реализована звуковая индикация подключения и отключения монитора.
6. При использовании Wayland реализована поддержка механизма "sticky keys" для людей c нарушенной мелкой моторикой.
Со списком всех изменений с приложенными изображениями, можно ознакомиться на русскоязычном ресурсе.
Есть тут фанаты KDE? Давайте проведем оценку:
Linux++ | IT-Образование
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍73🔥60🤔8🤷♂3🤮3❤1😁1
Учимся мониторить kernel
На днях, по рабочим задачам, мне нужно было выявить, какая версия ядра фиксит проблему. Тут, конечно же, пришлось вспомнить, как можно установить ядро, посмотреть его версию, запустить систему с целевым образом.
Ядро Linux - это один из самых важных компонентов операционной системы - буквально ее база и основа всех основ.
Самый распространенный способ посмотреть версию ядра - это команда uname. Она выводит некоторую системную информацию, в том числе, о ядре.
Чтобы исключить всю информацию, кроме нас интересующей, можно использовать флаг '-r':
Но это далеко не единственный способ справиться с задачей. Мы можем посмотреть строку запуска Grub с помощью команды:
Тут в параметре BOOT_IMAGE мы можем видеть полный путь к образу, который был загружен.
В той же файловой системе proc есть файл version, где хранится версия ядра:
Дальше, чтобы получить ту же информацию мы можем посмотреть лог dmesg, в самом начале которого отображается версия ядра:
Ага, а как можно посмотреть общий список образов, которые установлены в системе?
Тут тоже есть несколько способов. Во-первых, можно использовать пакетный менеджер:
Во-вторых, можно посмотреть содержимое папки boot и выловить от туда все образы ядра с именем vmlinuz:
В-третьих, используя тот же boot, а именно файл "/boot/grub/grub.cfg", можно посмотреть на все доступные версии:
Эта команда ищет строки, которые содержат слова menuentry либо submenu и передает их команде cat на вывод, которая, в свою очередь, предварительно прогоняет их через фильтр по разделителю (-f2 -d "'").
Linux++ | IT-Образование
На днях, по рабочим задачам, мне нужно было выявить, какая версия ядра фиксит проблему. Тут, конечно же, пришлось вспомнить, как можно установить ядро, посмотреть его версию, запустить систему с целевым образом.
Ядро Linux - это один из самых важных компонентов операционной системы - буквально ее база и основа всех основ.
Самый распространенный способ посмотреть версию ядра - это команда uname. Она выводит некоторую системную информацию, в том числе, о ядре.
Чтобы исключить всю информацию, кроме нас интересующей, можно использовать флаг '-r':
$ uname -r
6.8.0-41-generic
Но это далеко не единственный способ справиться с задачей. Мы можем посмотреть строку запуска Grub с помощью команды:
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.8.0-41-generic
Тут в параметре BOOT_IMAGE мы можем видеть полный путь к образу, который был загружен.
В той же файловой системе proc есть файл version, где хранится версия ядра:
$ cat /proc/version
Linux version 6.8.0-41-generic
Дальше, чтобы получить ту же информацию мы можем посмотреть лог dmesg, в самом начале которого отображается версия ядра:
$ sudo dmesg | grep Linux
Linux version 6.8.0-41-generic
Ага, а как можно посмотреть общий список образов, которые установлены в системе?
Тут тоже есть несколько способов. Во-первых, можно использовать пакетный менеджер:
$ sudo dpkg -l | grep linux-headers | grep ii | awk '{print $3}'
$ sudo rpm -q kernel
Во-вторых, можно посмотреть содержимое папки boot и выловить от туда все образы ядра с именем vmlinuz:
$ ls /boot | grep vmlinuz
vmlinuz
vmlinuz-6.8.0-36-generic
vmlinuz-6.8.0-41-generic
В-третьих, используя тот же boot, а именно файл "/boot/grub/grub.cfg", можно посмотреть на все доступные версии:
$ grep 'menuentry \|submenu ' /boot/grub/grub.cfg | cut -f2 -d "'"
Ubuntu, with Linux 6.8.0-41-generic
Ubuntu, with Linux 6.8.0-41-generic (recovery mode)
Эта команда ищет строки, которые содержат слова menuentry либо submenu и передает их команде cat на вывод, которая, в свою очередь, предварительно прогоняет их через фильтр по разделителю (-f2 -d "'").
Linux++ | IT-Образование
👍40🔥8❤2
Как не поломать sudo?
Настройки sudo по большей части находятся в файле /etc/sudoers. Для внесения изменений в этот файл крайне нежелательно использовать обычный редактор текста.
Дело в том, что некорректный синтаксис файла sudoers запросто может навредить операционной системе и поломать sudo.
И вот проблема, вы поломали sudo, что будем делать дальше, ведь файл /etc/sudoers может редактировать только превелигированный пользователь?)
У меня уже был однажды такой казус, правда, не из-за файла sudoers, но в результате, sudo отвалился. Пришлось чиниться через live образ, вам оно надо?)
Для редактирования файла существует специальная команда – visudo, которая обычно использует текстовый редактор vi и при сохранении изменений всегда проверяет синтаксис на корректность:
Если кто-то уже редактирует файл, вы получите предупреждение с просьбой попробовать позже и, если вы допустили ошибки, файл просто не будет сохранен.
Также, утилита блокирует sudoers для того, чтобы никто не мог одновременно с вами его изменять.
Если вам не нравится дефолтный текстовый редактор, visudo позволяет его изменить. Команда распологает встроенным списком поддерживаемых редакторов.
Для того, чтобы переопределить редактор, достаточно объявить переменную окружения EDITOR:
Для того, чтобы изменения применялись постоянно, вам требуется прописать команду выше в файл .bashrc для пользователя.
Linux++ | IT-Образование
Настройки sudo по большей части находятся в файле /etc/sudoers. Для внесения изменений в этот файл крайне нежелательно использовать обычный редактор текста.
Дело в том, что некорректный синтаксис файла sudoers запросто может навредить операционной системе и поломать sudo.
И вот проблема, вы поломали sudo, что будем делать дальше, ведь файл /etc/sudoers может редактировать только превелигированный пользователь?)
У меня уже был однажды такой казус, правда, не из-за файла sudoers, но в результате, sudo отвалился. Пришлось чиниться через live образ, вам оно надо?)
Для редактирования файла существует специальная команда – visudo, которая обычно использует текстовый редактор vi и при сохранении изменений всегда проверяет синтаксис на корректность:
$ sudo visudo
Если кто-то уже редактирует файл, вы получите предупреждение с просьбой попробовать позже и, если вы допустили ошибки, файл просто не будет сохранен.
Также, утилита блокирует sudoers для того, чтобы никто не мог одновременно с вами его изменять.
Если вам не нравится дефолтный текстовый редактор, visudo позволяет его изменить. Команда распологает встроенным списком поддерживаемых редакторов.
Для того, чтобы переопределить редактор, достаточно объявить переменную окружения EDITOR:
$ export EDITOR=nano
Для того, чтобы изменения применялись постоянно, вам требуется прописать команду выше в файл .bashrc для пользователя.
Linux++ | IT-Образование
👍39🔥9❤2
Пора обновляться на Kernel 6.11?
Серия ядер Linux 6.10 достигла конца срока поддержки, и вам следует рассмотреть возможность обновления до ядра Linux 6.11.
Ядро Linux 6.10 было выпущено 14 июля 2024 года и представило новые функции, среди которых:
1) системный вызов mseal() для защиты памяти;
2) поддержку языка Rust для архитектуры RISC-V;
3) поддержку сжатия Zstandard для файловой системы EROFS;
Ядро Linux 6.10 не является веткой с долгосрочной поддержкой (LTS), поэтому поддерживалось только несколько месяцев и получило четырнадцать обновлений.
Ядро Linux 6.11 было выпущено 15 сентября 2024 года и уже было принято различными популярными дистрибутивами: Ubuntu 24.10, Arch Linux, Fedora Linux и openSUSE Tumbleweed.
Данный релиз также является краткосрочным - будет поддерживаться несколько месяцев.
Если вам нужна долгосрочная поддержка, следует использовать либо Linux 6.6, либо Linux 6.1, обе версии будут поддерживаться до декабря 2026 года и являются LTS.
Вообще, честно говоря, новость новостью, но загоняться на счет версии ядра особо не стоит, если вам не требуются самые передовые фичи либо баг фиксы. Обновление ядра может привести к ряду проблем, если какие-то утилиты несовместимы с нововведениями.
Некоторые дистры на ядро накладывают ряд патчей, чтобы все работало и не ломалось. Лучше всего - дождаться стабильной версии дистрибутива и обновить все его компоненты, включая ядро.
Linux++ | IT-Образование
Серия ядер Linux 6.10 достигла конца срока поддержки, и вам следует рассмотреть возможность обновления до ядра Linux 6.11.
Ядро Linux 6.10 было выпущено 14 июля 2024 года и представило новые функции, среди которых:
1) системный вызов mseal() для защиты памяти;
2) поддержку языка Rust для архитектуры RISC-V;
3) поддержку сжатия Zstandard для файловой системы EROFS;
Ядро Linux 6.10 не является веткой с долгосрочной поддержкой (LTS), поэтому поддерживалось только несколько месяцев и получило четырнадцать обновлений.
Ядро Linux 6.11 было выпущено 15 сентября 2024 года и уже было принято различными популярными дистрибутивами: Ubuntu 24.10, Arch Linux, Fedora Linux и openSUSE Tumbleweed.
Данный релиз также является краткосрочным - будет поддерживаться несколько месяцев.
Если вам нужна долгосрочная поддержка, следует использовать либо Linux 6.6, либо Linux 6.1, обе версии будут поддерживаться до декабря 2026 года и являются LTS.
Вообще, честно говоря, новость новостью, но загоняться на счет версии ядра особо не стоит, если вам не требуются самые передовые фичи либо баг фиксы. Обновление ядра может привести к ряду проблем, если какие-то утилиты несовместимы с нововведениями.
Некоторые дистры на ядро накладывают ряд патчей, чтобы все работало и не ломалось. Лучше всего - дождаться стабильной версии дистрибутива и обновить все его компоненты, включая ядро.
Linux++ | IT-Образование
👍26❤🔥4🔥2
Слышали про chroot?
Chroot (change root) - это утилита, которая используется для того, чтобы создать закрытое окружение "тюрьму", в которой программа будет видеть определенную часть файловой системы, как корневую '/'.
Это похоже на создание миниатюрного "сейфа" или "контейнера" для запуска приложений. В качестве примера можете вспомнить тот же Docker.
Под капотом chroot использует одноименный системный вызов и в некоторых ситуациях может пригодиться, как дополнительный элемент безопасности, который позволит ограничить набор каталогов и файлов, доступных программе.
Системный вызов chroot()
Каждый процесс обладает корневым каталогом — он представляет собой стартовую точку, от которой интерпретируются абсолютные имена путей, начинающиеся с символа '/'. По умолчанию данным каталогом является реальный корневой каталог файловой системы.
Иногда бывает удобно, чтобы процесс изменил свой корневой каталог. Это может реализовать с помощью системного вызова chroot(). Системный вызов chroot() изменяет корневой каталог процесса на каталог, указанный в аргументе pathname:
Затем все абсолютные имена путей интерпретируются, как начинающиеся с указанного местоположения в файловой системе. Иногда это называют заключением в клетку chroot, поскольку программа оказывается замкнутой внутри некоторой части файловой системы.
Моменты, которые стоит учитывать при работе с chroot
Следует 100% помнить, что вызов chroot() не меняет текущий рабочий каталог процесса. Для обеспечения полной безопасности, либо перед, либо после chroot() необходимо выполнить вызов chdir(), иначе процесс сможет использовать относительные пути для доступа к ресурсам вне клетки.
Также, при переходе в пространство chroot, вы можете столкнуться с тем, что ничего не работает) Это и не удивительно, как оболочка будет выполнять команды, которых для нее просто не существует...
Для решения проблемы вам может понадобиться перенести ряд библиотек и программ из "реальной" корневой системы в имитированную либо использовать команду debootstrap, но это уже отдельная история)
Linux++ | IT-Образование
Chroot (change root) - это утилита, которая используется для того, чтобы создать закрытое окружение "тюрьму", в которой программа будет видеть определенную часть файловой системы, как корневую '/'.
Это похоже на создание миниатюрного "сейфа" или "контейнера" для запуска приложений. В качестве примера можете вспомнить тот же Docker.
Под капотом chroot использует одноименный системный вызов и в некоторых ситуациях может пригодиться, как дополнительный элемент безопасности, который позволит ограничить набор каталогов и файлов, доступных программе.
Системный вызов chroot()
Каждый процесс обладает корневым каталогом — он представляет собой стартовую точку, от которой интерпретируются абсолютные имена путей, начинающиеся с символа '/'. По умолчанию данным каталогом является реальный корневой каталог файловой системы.
Иногда бывает удобно, чтобы процесс изменил свой корневой каталог. Это может реализовать с помощью системного вызова chroot(). Системный вызов chroot() изменяет корневой каталог процесса на каталог, указанный в аргументе pathname:
#include <unistd.h>
int chroot(const char *pathname);
Затем все абсолютные имена путей интерпретируются, как начинающиеся с указанного местоположения в файловой системе. Иногда это называют заключением в клетку chroot, поскольку программа оказывается замкнутой внутри некоторой части файловой системы.
Моменты, которые стоит учитывать при работе с chroot
Следует 100% помнить, что вызов chroot() не меняет текущий рабочий каталог процесса. Для обеспечения полной безопасности, либо перед, либо после chroot() необходимо выполнить вызов chdir(), иначе процесс сможет использовать относительные пути для доступа к ресурсам вне клетки.
Также, при переходе в пространство chroot, вы можете столкнуться с тем, что ничего не работает) Это и не удивительно, как оболочка будет выполнять команды, которых для нее просто не существует...
Для решения проблемы вам может понадобиться перенести ряд библиотек и программ из "реальной" корневой системы в имитированную либо использовать команду debootstrap, но это уже отдельная история)
Linux++ | IT-Образование
👍32🔥7❤3⚡1🤯1
Микротуториал по управлению пакетами (Debian-based)
В Linux и разработчики и обычные пользователи довольно часто работают с бинарными пакетами: обновляют их, удаляют, переустанавливают, смотрят описание, мониторят содержимое.
Сегодня мы рассмотрим пулл команд по работе с пакетами, которые, на практике, чаще всего используются в "Debian-based" системах.
Если интересно подробнее изучить, что такое бинарный пакет, пакетный менеджер и для чего все это нужно, отсылаю вас на мой ранний пост.
Основные команды apt
1. Обновляет локальный кэш с информацией о доступных пакетах и их версиях из репозиториев, прописанных в "/etc/apt/sources.list":
2. Обновляет все установленные пакеты до актуальных версий, НО существующие пакеты не удаляет.
Если для обновления требуется удаление/установка зависимостей, оно пропускается, и пакет остается нетронутым в текущей версии:
3. Обновляет все установленные пакеты до актуальных версий, устанавливает или удаляет пакеты для разрешения зависимостей:
4. Устанавливает пакет вместе со всеми его зависимостями:
5. Переустанавливает пакет и обновляет все его содержимое. Бывает полезно, если какие-то файлы пакета были удалены или повреждены:
6. Удаляет указанный пакет, но оставляет файлы конфигурации:
7. Полностью удаляет пакет и его конфигурационные файлы:
8. Показывает информацию о пакете: версия, зависимости, описание, размер и т.д.:
9. Ищет пакеты в репозиториях по имени или описанию:
10. Удаляет пакеты, которые были установлены как зависимости, но больше не требуются:
11. Удаляет все загруженные архивы пакетов из кэша "/var/cache/apt/archives/":
Основные команды dpkg
1. Устанавливает пакет из локального файла .deb и не подтягивает зависимости:
2. Удаляет пакет, но сохраняет конфигурационные файлы:
3. Полностью удаляет пакет и его конфигурационные файлы:
4. Показывает список всех установленных пакетов либо информацию о конкретном пакете:
5. Выводит подробную информацию о пакете/пакетах:
6. Показывает список файлов, установленных данным пакетом:
7. Показывает содержимое архива .deb (файлы, которые будут установлены):
8. Доводит конфигурацию пакета/пакетов до конца при аварийном завершении:
9. Показывает имя пакета, который устанавливает указанный файл:
Linux++ | IT-Образование
В Linux и разработчики и обычные пользователи довольно часто работают с бинарными пакетами: обновляют их, удаляют, переустанавливают, смотрят описание, мониторят содержимое.
Сегодня мы рассмотрим пулл команд по работе с пакетами, которые, на практике, чаще всего используются в "Debian-based" системах.
Если интересно подробнее изучить, что такое бинарный пакет, пакетный менеджер и для чего все это нужно, отсылаю вас на мой ранний пост.
Основные команды apt
1. Обновляет локальный кэш с информацией о доступных пакетах и их версиях из репозиториев, прописанных в "/etc/apt/sources.list":
$ sudo apt update
2. Обновляет все установленные пакеты до актуальных версий, НО существующие пакеты не удаляет.
Если для обновления требуется удаление/установка зависимостей, оно пропускается, и пакет остается нетронутым в текущей версии:
$ sudo apt upgrade
3. Обновляет все установленные пакеты до актуальных версий, устанавливает или удаляет пакеты для разрешения зависимостей:
$ sudo apt dist-upgrade
4. Устанавливает пакет вместе со всеми его зависимостями:
$ sudo apt install <имя_пакета>
5. Переустанавливает пакет и обновляет все его содержимое. Бывает полезно, если какие-то файлы пакета были удалены или повреждены:
$ sudo apt install --reinstall <имя_пакета>
6. Удаляет указанный пакет, но оставляет файлы конфигурации:
$ sudo apt remove <имя_пакета>
7. Полностью удаляет пакет и его конфигурационные файлы:
$ sudo apt purge <имя_пакета>
8. Показывает информацию о пакете: версия, зависимости, описание, размер и т.д.:
$ sudo apt show <имя_пакета>
9. Ищет пакеты в репозиториях по имени или описанию:
$ sudo apt search <имя_пакета>
10. Удаляет пакеты, которые были установлены как зависимости, но больше не требуются:
$ sudo apt autoremove
11. Удаляет все загруженные архивы пакетов из кэша "/var/cache/apt/archives/":
$ sudo apt clean
Основные команды dpkg
1. Устанавливает пакет из локального файла .deb и не подтягивает зависимости:
$ sudo dpkg -i <имя_пакета.deb>
2. Удаляет пакет, но сохраняет конфигурационные файлы:
$ sudo dpkg -r <имя_пакета>
3. Полностью удаляет пакет и его конфигурационные файлы:
$ sudo dpkg -P <имя_пакета>
4. Показывает список всех установленных пакетов либо информацию о конкретном пакете:
$ dpkg -l
$ dpkg -l <имя_пакета>
5. Выводит подробную информацию о пакете/пакетах:
$ dpkg -s
$ dpkg -s <имя_пакета>
6. Показывает список файлов, установленных данным пакетом:
$ dpkg -L <имя_пакета>
7. Показывает содержимое архива .deb (файлы, которые будут установлены):
$ dpkg -c <имя_пакета.deb>
8. Доводит конфигурацию пакета/пакетов до конца при аварийном завершении:
$ sudo dpkg --configure -a
$ sudo dpkg --configure <имя_пакета>
9. Показывает имя пакета, который устанавливает указанный файл:
$ dpkg -S picom.desktop
picom: /etc/xdg/autostart/picom.desktop
Linux++ | IT-Образование
6👍59🔥12❤3🤯2🤬1