Как сделать так что бы у приложения в Linux/Windows был доступ к файлам, а у пользователя нет?

Question

[MechanicZelenyy]

Разрабатывается приложение к которого предполагается следующий функционал:
Есть низкопривилегированный пользователь, который запускает приложение.
При запуске приложения открывается сессия и в рамках работы пользователя в этой сессии создаются данные, которые сессия умеет хранить локально где-то на диске. Где можно почитать как настроить права доступа приложения и пользователя так чтобы приложение имело доступ на запись/чтение этих сохранённых данных, а пользователь нет?

UPD:

Приложение: программа для лабораторных работ, типичные аналогичные программы хранят данные только в памяти и могут их сохранять в любое доступное пользователю место, как результат рабочая машина превращается в помойку, потому что студенты работают из под одного пользователя, пересохраняются на каждое измерение (а моргание света вообще может быть sad story). Есть желание все это цивилизовать, сделать какой то механизм для автосохранения данных и соответственно недоступное пользователю хранилище этих данных ( в условиях автономности работы от сети и без всяких ИБП). Недоступное чтоб студенты не тырили и не портили чужие данные.

Рассматриваются варианты не только через права доступа,но и через экраны типа apparmor

Answer 1

[Rsa97]

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

Comments

[MechanicZelenyy]

Да, я тоже думал о таком решении, но для относительного простого приложения мне показалось лишним держать дополнительный сервис, и захотелось узнать нельзя ли сделать это на правах доступа или иных системных функциях.

[Василий Банников]

MechanicZelenyy, права доступа выдаются как раз на пользователя или группу, но проблема в том, что чтобы у программы были права - она должна быть запущена от имени этого привилегированного пользователя, что в нашем случае невозможно, если это обычная программа, а не служба или демон.

[Rsa97]

MechanicZelenyy, В линуксе можно дать пользователю право запускать конкретную программу от другого пользователя, описав это в файле /etc/sudoers.

Answer 2

[Василий Банников]

1. Создаёшь нового "привилегированного" пользователя
2. Выдаёшь этому пользователю права на чтение и запись в определённую директорию
3. У "непривилегированного" пользователя забираешь права на чтение и запись в эту директорию
4. Запускаешь программу от имени "привилегированного" пользователя.
5. Чтобы непривилегированный пользователь мог работать с программой - разделяешь её на две части.
Первая часть - служба/демон, который работает в фоне. Он будет запускаться системой автоматически от имени привилегированного пользователя.
Вторая часть - клиент, который будет обращаться к фоновой службе. Клиент будет запускаться непривилегированным пользователем тогда, когда ему это нужно.

Больше способов нет.

Comments

[MechanicZelenyy]

Пусть это не делается через права доступа, но что насчёт других системных служб?

[Василий Банников]

MechanicZelenyy, SYSTEM и root имеют полный доступ ко всем директориям, на то они и системные.
Ограничение доступа к директориям работает исключительно на уровне ОС. Сами данные остаются на диске в незашифрованном виде.

[MechanicZelenyy]

Василий Банников, нет, я про то есть ли какой-нибудь способ (желательно, на основе дефолтно установленного в системе пакета), просто написать в каком-нибудь конфиге правило что programm_name может читать/писать в заданную не доступную пользователю директорию,

[Василий Банников]

MechanicZelenyy,
1. Как ОС должна понять, что это именно "та самая" программа?
2. Какую конкретно задачу/проблему хочется таким способом ограничения папок решить?
Должен быть другой, более идеоматичный способ

[MechanicZelenyy]

Василий Банников, 1) Например по имени команды, htop же видит какой командой запущен процесс, при этом это безопасно, в условно /usr/local/bin/ пользователь имя не меняет.
2) Дать доступ к данным программе, но не пользователю, не разводя зоопарк из сервисов/демонов/серверов

[Василий Банников]

MechanicZelenyy, почему у пользователя не должно быть доступа к этим данным?

[MechanicZelenyy]

Василий Банников, чтобы например студенты не катали данные с прошлых работ

[Василий Банников]

MechanicZelenyy,
Типа если два студента используют один компьютер по очереди?

Почему бы для каждого студента не завести свою учётку - тогда у каждого будет свой набор файлов.

Это же вполне обычная практика и это очень легко решается через active directory.

Ещё вариант - не хранить работы на студенческом компьютере вообще.

[MechanicZelenyy]

Василий Банников, 800-1000 студентов на курс, проще сделать привелигированного демона которые хранит данныеи и сделать юнит в systemd.

Answer 3

[pfg21]

вариант2: программа запускается под другим пользователем, которому доступны права, не доступные для запускающего пользователя.
смотри биты setuid setgid для исполняемого файла. такой исполняемый файл система запускает с uid/gid пользователя, прописанного в свойствах файла.
используется, к примеру, в sudo и многих других для того, чтобы sudo запускался с правами root в независимости от запускающего пользователя.

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

Comments

[MechanicZelenyy]

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

Answer 4

[Adamos]

Нелепая постановка задачи. Приложение запускается от имени пользователя и имеет его права - это базовая логика системы, выдумывать тут способ взяться за ухо через коленку просто глупо.
Стоит вернуться к вопросу, зачем это делается, и решать проблему более естественным способом.

Comments

[MechanicZelenyy]

Задача чтоб запущенное пользователем приложение имело доступ к данным, а пользователь нет.

[Adamos]

MechanicZelenyy, а вопрос "зачем" автор ТЗ не проходил?

[MechanicZelenyy]

Adamos, я сам себе и автор и исполнитель, Приложение: программа для лабораторных работ, типичные аналогичные программы хранят данные только в памяти и могут их сохранять в любое доступное пользователю место, как результат рабочая машина превращается в помойку, потому что студенты работают из под одного пользователя, пересохраняются на каждое измерение (а моргание света вообще может быть sad story). Есть желание все это цивилизовать, сделать какой то механизм для автосохранения данных и соответственно недоступное пользователю хранилище этих данных ( в условиях автономности работы от сети и без всяких ИБП). Недоступное чтоб студенты не тырили и не портили чужие данные.

[Adamos]

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

[MechanicZelenyy]

Я понимаю что использование веб-сервиса решает проблему, однако если из отвала интернета студенты не могут делать работу, то это харам

[Adamos]

MechanicZelenyy, веб-сервис может работать на самом компьютере или локальном сервере.

[Adamos]

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

[MechanicZelenyy]

Adamos, Да это собственно ничем не отличается с от варианта с демоном для хранения, но вопрос в том можно ли сэкономить усилия и не писать отдельную программу для хранения

[Adamos]

MechanicZelenyy, велосипеды с разведением демонов ничем не отличаются от мейнстримного решения проблем, к которому рано или поздно все равно сведется это рукоблудие? Да ладно.

[MechanicZelenyy]

Adamos, Да это нормальный вариант для софта, там конечно надо аккуратно сделать чтоб студенты не уводили друг у друга девайсы, но тут вопрос про конкретно десктопное приложение.

[MechanicZelenyy]

Adamos, веб-сервис это внезапно тот же демон передающий данные через сокет. Собственно я понимаю что можно рещить проблему написав клиент и сервер (не важно как вы его назовёте демоном или веб-сервисом), но возникает вопрос не оверинжиниринг ли это и нельзя ли обойтись только одним приложением.

[Adamos]

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

[MechanicZelenyy]

Adamos, Мы кажется не много не понимаем друг друга в терминах. Конечно я не собираюсь писать свой-веб-сервер или браузер. Под оверинжинирингом я понимаю что вместо одного десктопного приложения на нативном Qt for Python, писать отдельно бэкенд и отдельно браузерный UI фронтед это не много перебор