R>>>Навредить не реально, данные имеют цифровую подпись. O>>И прям стопроцентов уверены что проверка не уязвима например к TOCTOU? vsb>Сначала читаем в память, потом проверяем и потом используем из памяти.
Хорошо если оно так и сделано. Кстати далеко не всегда можно так сделать — иногда все данные просто не влазят в память, и приходится костылять всякие там merkle tree.
O>>А если например какой нить злой юзер положит ковявые файлы или пермишены на них. Все остальные смогут работать или таки DoS атака окажется успешной? vsb>Загружаем заново и кладём на нужное место. Злой юзер сможет потратить трафик.
А злой юзер настолько злой, что повесил inotify и ломает ваши данные как только вы их загрузите.
Как много веселых ребят, и все делают велосипед...
vsb>> Создайте инсталлятором папку /var/cache/myprogram и дайте ей нужные права, хоть 777 (но лучше 770 и создать отдельную группу для пользователей вашей программы). R>Софт распространяется в виде appimage, инсталлятора нет.
Ну назовем это 1st run initialization, с запуском под sudo.
Как много веселых ребят, и все делают велосипед...
vsb>Вообще защищаться от злого юзера — тухлое дело. Защищаться надо от глупого юзера. Который что-то по ошибке может сделать. Например почистить эти самые кеши какой-нибудь кривой командой вроде echo > /var/caches/myprogram/download000.dat А если он реально злой — тут вы, скорей всего, уже проиграли. Потому, что он заюзает какой-нибудь local escalation exploit которых слишком много, чтобы считать их теоретическими и вот уже он злой root.
Это нифига не unix way. А количество local escalation exploit-ов на апдейтящейся системе примерно равно нулю.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, rudzuk, Вы писали:
k>> /usr/share k>> /usr/local/share
R>У обычного юзера нет прав на запись сюда, а данные приложения изменяемые. Хочется избежать дублирования большого объема данных. Софт распространяется в виде appimage.
Так сделайте папку и дайте на неё права если надо, при вервом запуске или сваливайте всё к текущему пользователю. Если хочется то можно sudo mount --bind /usr/local/share/myapp/cache ~/.local/share/myapp/cache
/usr/local/share/myapp/cache
/usr/local/share/myapp/data
Здравствуйте, ononim, Вы писали:
R>>>>Навредить не реально, данные имеют цифровую подпись. O>>>И прям стопроцентов уверены что проверка не уязвима например к TOCTOU? vsb>>Сначала читаем в память, потом проверяем и потом используем из памяти. O>Хорошо если оно так и сделано. Кстати далеко не всегда можно так сделать — иногда все данные просто не влазят в память, и приходится костылять всякие там merkle tree.
Да, если не влазит в память, это будет весьма нетривиальная задача.
O>>>А если например какой нить злой юзер положит ковявые файлы или пермишены на них. Все остальные смогут работать или таки DoS атака окажется успешной? vsb>>Загружаем заново и кладём на нужное место. Злой юзер сможет потратить трафик. O>А злой юзер настолько злой, что повесил inotify и ломает ваши данные как только вы их загрузите.
Грузим в память, сохраняем на диски, используем из памяти.
Здравствуйте, rudzuk, Вы писали:
r> Куда в линуксе принято сохранять разделяемые между локальными пользователями изменяемые данные приложения? В Windows эту задачу решает ProgramData, а в линуксе? FHS смотрел, но ничего похожего не нашел
В общем, решили добавить путь к разделяемым данным в конфиг. Всем спасибо за участие.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Тогда было бы правильнее иметь независимую службу (демон), загружающую/обновляющую эти данные. Делать это непосредственно из приложения допустимо лишь в том случае, когда все без исключения пользователи системы (и локальные, и сетевые) являются доверенными, и никак не могут навредить.
Не обязательно. Даже со стандартными правами ugo*rwx можно делать следующее:
1. Все пользователи, участвующие в данном хранилище, входят в назначенную группу — и только она будет иметь соответствующие права.
2. Все операции по созданию файлов и каталогов в хранилище сопровождаются chgrp() на эту группу.
3. Все операции по созданию файлов и каталогов в хранилище выставляют права g+rw для файлов и g+rwx для каталогов. (Можно это сделать через umask(2) перед такими операциями.)
Да, тут потребуется дисциплина доступа, но это для данной ситуации явно не страшно.
С расширенными ACL, которые сейчас чуть менее, чем везде, можно делать то же самое и ещё больше.
Вариант с демоном неплох по-своему, но можно и без него.
Здравствуйте, rudzuk, Вы писали:
R>Приложение работает с большим объемом данных, которые, на начальном этапе, загружаются из интернет. В процессе работы, приложение эти данные не изменяет, но, иногда, загружает обновления для них. Сейчас данные хранятся в ~/.local/share/appname, но очень хочется избежать дублирования данных, когда приложение используется несколькими локальными пользователями.
Тогда это скорее /var/cache/app-name (app-name — имя программы).
Я бы разбил эту конструкцию на два процесса. Один — демон, имеющий право записи в /var/cache/..., и отвечающий за подгрузку необходимого. Другой — пользовательская программа, с read-only доступом к данным.
А то нехорошо получится, если кто-то из пользователей нагадит в общие данные.
Здравствуйте, rudzuk, Вы писали:
ЕМ>> Тогда было бы правильнее иметь независимую службу (демон), загружающую/обновляющую эти данные. Делать это непосредственно из приложения допустимо лишь в том случае, когда все без исключения пользователи системы (и локальные, и сетевые) являются доверенными, и никак не могут навредить.
R>Навредить не реально, данные имеют цифровую подпись.
Ну, удаление их — это тоже вред. Иначе какой смысл их подкачивать?
Хватит пропагандировать бредятину. Для данных приложения — /var/lib/myapp, для кэша — /var/cache/myapp.
> /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere. https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04.html#purpose18
Здравствуйте, rudzuk, Вы писали:
R>Куда в линуксе принято сохранять разделяемые между локальными пользователями изменяемые данные приложения? В Windows эту задачу решает ProgramData, а в линуксе? FHS смотрел, но ничего похожего не нашел
Linux сетевая ос, понятие локальный пользователь относительно, там чаще используется понятие хоста на который вошел юзер (localhost или server не принципиально).
Доступен только /home/usr и /tmp.
Лучше БД для хранения общих данных ничего нет.
Здравствуйте, rudzuk, Вы писали:
R>Куда в линуксе принято сохранять разделяемые между локальными пользователями изменяемые данные приложения? В Windows эту задачу решает ProgramData, а в линуксе? FHS смотрел, но ничего похожего не нашел
как же не нашел? 3ю версию смотрел или вторую?
4.9.4
неизменяемые — /usr/local/share (для программ не из дистрибутива), /usr/share — только для программ из дистрибутива
Здравствуйте, netch80, Вы писали:
N>2. Все операции по созданию файлов и каталогов в хранилище сопровождаются chgrp() на эту группу. N>Да, тут потребуется дисциплина доступа, но это для данной ситуации явно не страшно.
Здравствуйте, rudzuk, Вы писали:
R>Софт распространяется в виде appimage, инсталлятора нет.
Увольте предложившего распространять таким образом и наймите более годного девапса.
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, vsb, Вы писали:
vsb>> Создайте инсталлятором папку /var/cache/myprogram и дайте ей нужные права, хоть 777 (но лучше 770 и создать отдельную группу для пользователей вашей программы).
R>Софт распространяется в виде appimage, инсталлятора нет.
добавте в образ appname-config.sh, если еще не добавили. так все делают. из известных например mysql и postresql. надо было с самого начала начинать с этого скрипта/бинарника. у вас ни одного что ли опытного пользователя линукс нет?
