Здравствуйте, rudzuk, Вы писали:

R>Приложение работает с большим объемом данных, которые, на начальном этапе, загружаются из интернет.

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

Здравствуйте, vsb, Вы писали:

vsb> Создайте инсталлятором папку /var/cache/myprogram и дайте ей нужные права, хоть 777 (но лучше 770 и создать отдельную группу для пользователей вашей программы).

Софт распространяется в виде appimage, инсталлятора нет.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Тогда было бы правильнее иметь независимую службу (демон), загружающую/обновляющую эти данные. Делать это непосредственно из приложения допустимо лишь в том случае, когда все без исключения пользователи системы (и локальные, и сетевые) являются доверенными, и никак не могут навредить.

Не обязательно. Даже со стандартными правами ugo*rwx можно делать следующее:
1. Все пользователи, участвующие в данном хранилище, входят в назначенную группу — и только она будет иметь соответствующие права.
2. Все операции по созданию файлов и каталогов в хранилище сопровождаются chgrp() на эту группу.
3. Все операции по созданию файлов и каталогов в хранилище выставляют права g+rw для файлов и g+rwx для каталогов. (Можно это сделать через umask(2) перед такими операциями.)

Да, тут потребуется дисциплина доступа, но это для данной ситуации явно не страшно.

С расширенными ACL, которые сейчас чуть менее, чем везде, можно делать то же самое и ещё больше.

Вариант с демоном неплох по-своему, но можно и без него.

Здравствуйте, rudzuk, Вы писали:

R>Куда в линуксе принято сохранять разделяемые между локальными пользователями изменяемые данные приложения? В Windows эту задачу решает ProgramData, а в линуксе? FHS смотрел, но ничего похожего не нашел
/usr/share
/usr/local/share

Здравствуйте, rudzuk, Вы писали:

R>В /var/cache доступа на запись нет.

Создайте инсталлятором папку /var/cache/myprogram и дайте ей нужные права, хоть 777 (но лучше 770 и создать отдельную группу для пользователей вашей программы).

_>/usr/local/share/myapp/cache
_>/usr/local/share/myapp/data



Хватит пропагандировать бредятину. Для данных приложения — /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 смотрел, но ничего похожего не нашел

как же не нашел? 3ю версию смотрел или вторую?

4.9.4
неизменяемые — /usr/local/share (для программ не из дистрибутива), /usr/share — только для программ из дистрибутива

5.
изменяемые — /var/lib, /var/opt, /var/cache, /var/share

если тебе данные можно загрузить из интернета, то /var/cache/appname
если нужно что бы при backup системы сохранялись, то /var/lib/appname

Куда в линуксе принято сохранять разделяемые между локальными пользователями изменяемые данные приложения? В Windows эту задачу решает ProgramData, а в линуксе? FHS смотрел, но ничего похожего не нашел

Здравствуйте, kov_serg, Вы писали:

_>/usr/share
_>/usr/local/share

Тут надо добавить, что эти каталоги доступны на запись только аккаунтам с повышенными правами, рядовые пользователи могут только читать (и это правильно). Если какой-то код или данные нужно разделять на чтение между пользователями, то внести их туда должен администратор при установке/настройке. А в винде ProgramData — в первую очередь неконтролируемая свалка для приложений, сделанных раздолбаями, которые до сих пор не научились правильно организовывать доступ, и лишь в последнюю — средство для разделения данных между пользователями.

_>/usr/share
_>/usr/local/share

/var/lib

Здравствуйте, kov_serg, Вы писали:

k> R>Куда в линуксе принято сохранять разделяемые между локальными пользователями изменяемые данные приложения? В Windows эту задачу решает ProgramData, а в линуксе? FHS смотрел, но ничего похожего не нашел

k> /usr/share
k> /usr/local/share

У обычного юзера нет прав на запись сюда, а данные приложения изменяемые. Хочется избежать дублирования большого объема данных. Софт распространяется в виде appimage.

Здравствуйте, rudzuk, Вы писали:

k>> /usr/share
k>> /usr/local/share

R>У обычного юзера нет прав на запись сюда, а данные приложения изменяемые.

А какова вообще модель разделения данных между пользователями? Если это для совместной работы в группе, то и общий каталог нужно делать для группы, с соответствующими правами доступа. Если же это нечто вроде свалки "для всех" (в том числе и сетевых гостей), то действительно ли это вытекает из логики работы приложения?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> R>У обычного юзера нет прав на запись сюда, а данные приложения изменяемые.

ЕМ> А какова вообще модель разделения данных между пользователями? Если это для совместной работы в группе, то и общий каталог нужно делать для группы, с соответствующими правами доступа. Если же это нечто вроде свалки "для всех" (в том числе и сетевых гостей), то действительно ли это вытекает из логики работы приложения?

Приложение работает с большим объемом данных, которые, на начальном этапе, загружаются из интернет. В процессе работы, приложение эти данные не изменяет, но, иногда, загружает обновления для них. Сейчас данные хранятся в ~/.local/share/appname, но очень хочется избежать дублирования данных, когда приложение используется несколькими локальными пользователями.

Здравствуйте, rudzuk, Вы писали:

R>Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>> R>У обычного юзера нет прав на запись сюда, а данные приложения изменяемые.

ЕМ>> А какова вообще модель разделения данных между пользователями? Если это для совместной работы в группе, то и общий каталог нужно делать для группы, с соответствующими правами доступа. Если же это нечто вроде свалки "для всех" (в том числе и сетевых гостей), то действительно ли это вытекает из логики работы приложения?

R>Приложение работает с большим объемом данных, которые, на начальном этапе, загружаются из интернет. В процессе работы, приложение эти данные не изменяет, но, иногда, загружает обновления для них. Сейчас данные хранятся в ~/.local/share/appname, но очень хочется избежать дублирования данных, когда приложение используется несколькими локальными пользователями.

Звучит как кандидат для /var/caches/ или /var/tmp

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> Тогда было бы правильнее иметь независимую службу (демон), загружающую/обновляющую эти данные. Делать это непосредственно из приложения допустимо лишь в том случае, когда все без исключения пользователи системы (и локальные, и сетевые) являются доверенными, и никак не могут навредить.

Навредить не реально, данные имеют цифровую подпись.

Здравствуйте, Михaил, Вы писали:

М> R>Приложение работает с большим объемом данных, которые, на начальном этапе, загружаются из интернет. В процессе работы, приложение эти данные не изменяет, но, иногда, загружает обновления для них. Сейчас данные хранятся в ~/.local/share/appname, но очень хочется избежать дублирования данных, когда приложение используется несколькими локальными пользователями.

М> Звучит как кандидат для /var/caches/ или /var/tmp

Обе локации не гарантируют длительного хранения.

Здравствуйте, rudzuk, Вы писали:

R>Здравствуйте, Михaил, Вы писали:

М>> R>Приложение работает с большим объемом данных, которые, на начальном этапе, загружаются из интернет. В процессе работы, приложение эти данные не изменяет, но, иногда, загружает обновления для них. Сейчас данные хранятся в ~/.local/share/appname, но очень хочется избежать дублирования данных, когда приложение используется несколькими локальными пользователями.

М>> Звучит как кандидат для /var/caches/ или /var/tmp

R>Обе локации не гарантируют длительного хранения.

если пользователь вручную не удалит, они никуда не денутся. как и с програмдата

Здравствуйте, Михaил, Вы писали:

М>>> Звучит как кандидат для /var/caches/ или /var/tmp

R>>Обе локации не гарантируют длительного хранения.

М>если пользователь вручную не удалит, они никуда не денутся. как и с програмдата

/var/tmp обычно чистится по крону.

Здравствуйте, Михaил, Вы писали:

М> М>> Звучит как кандидат для /var/caches/ или /var/tmp

М> R>Обе локации не гарантируют длительного хранения.

М> если пользователь вручную не удалит, они никуда не денутся. как и с програмдата

Про /var/tmp написано:

Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp.

То есть, вероятность удаления не нулевая.

В /var/cache доступа на запись нет.

R>Навредить не реально, данные имеют цифровую подпись.
И прям стопроцентов уверены что проверка не уязвима например к TOCTOU?
А если например какой нить злой юзер положит ковявые файлы или пермишены на них. Все остальные смогут работать или таки DoS атака окажется успешной?

Здравствуйте, ononim, Вы писали:

R>>Навредить не реально, данные имеют цифровую подпись.
O>И прям стопроцентов уверены что проверка не уязвима например к TOCTOU?

Сначала читаем в память, потом проверяем и потом используем из памяти.

O>А если например какой нить злой юзер положит ковявые файлы или пермишены на них. Все остальные смогут работать или таки DoS атака окажется успешной?

Загружаем заново и кладём на нужное место. Злой юзер сможет потратить трафик.

Вообще защищаться от злого юзера — тухлое дело. Защищаться надо от глупого юзера. Который что-то по ошибке может сделать. Например почистить эти самые кеши какой-нибудь кривой командой вроде echo > /var/caches/myprogram/download000.dat А если он реально злой — тут вы, скорей всего, уже проиграли. Потому, что он заюзает какой-нибудь local escalation exploit которых слишком много, чтобы считать их теоретическими и вот уже он злой root.

Здравствуйте, ononim, Вы писали:

o> R>Навредить не реально, данные имеют цифровую подпись.

o> И прям стопроцентов уверены что проверка не уязвима например к TOCTOU?

Прям уверены.

o> А если например какой нить злой юзер положит ковявые файлы или пермишены на них. Все остальные смогут работать или таки DoS атака окажется успешной?

Задачи оборонятся от пользователя нет. Пользователь достаточно хорошо мотивирован.

o>> И прям стопроцентов уверены что проверка не уязвима например к TOCTOU?
R>Прям уверены.
ну если уверены тогда ладно

o>> А если например какой нить злой юзер положит ковявые файлы или пермишены на них. Все остальные смогут работать или таки DoS атака окажется успешной?
R>Задачи оборонятся от пользователя нет. Пользователь достаточно хорошо мотивирован.
тогда логиньте всех от рута и нет проблем

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 смотрел, но ничего похожего не нашел

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

Здравствуйте, rudzuk, Вы писали:

R>Хочется избежать дублирования
R>Софт распространяется в виде appimage.

Тут какое-то противоерчие.

Здравствуйте, wildwind, Вы писали:

w> R>Хочется избежать дублирования
w> R>Софт распространяется в виде appimage.

w> Тут какое-то противоерчие.

Если цитировать корректно, то нет.

Здравствуйте, vsb, Вы писали:

vsb>Создайте инсталлятором папку
_>Так сделайте папку

Мда, вот она, деградация терминологии...

Здравствуйте, rudzuk, Вы писали:

R>Приложение работает с большим объемом данных, которые, на начальном этапе, загружаются из интернет. В процессе работы, приложение эти данные не изменяет, но, иногда, загружает обновления для них. Сейчас данные хранятся в ~/.local/share/appname, но очень хочется избежать дублирования данных, когда приложение используется несколькими локальными пользователями.

Тогда это скорее /var/cache/app-name (app-name — имя программы).

Я бы разбил эту конструкцию на два процесса. Один — демон, имеющий право записи в /var/cache/..., и отвечающий за подгрузку необходимого. Другой — пользовательская программа, с read-only доступом к данным.

А то нехорошо получится, если кто-то из пользователей нагадит в общие данные.

Здравствуйте, rudzuk, Вы писали:

ЕМ>> Тогда было бы правильнее иметь независимую службу (демон), загружающую/обновляющую эти данные. Делать это непосредственно из приложения допустимо лишь в том случае, когда все без исключения пользователи системы (и локальные, и сетевые) являются доверенными, и никак не могут навредить.

R>Навредить не реально, данные имеют цифровую подпись.

Ну, удаление их — это тоже вред. Иначе какой смысл их подкачивать?

Здравствуйте, rudzuk, Вы писали:

R>Куда в линуксе принято сохранять разделяемые между локальными пользователями изменяемые данные приложения? В Windows эту задачу решает ProgramData, а в линуксе? FHS смотрел, но ничего похожего не нашел

Linux сетевая ос, понятие локальный пользователь относительно, там чаще используется понятие хоста на который вошел юзер (localhost или server не принципиально).
Доступен только /home/usr и /tmp.
Лучше БД для хранения общих данных ничего нет.

Здравствуйте, netch80, Вы писали:

N>2. Все операции по созданию файлов и каталогов в хранилище сопровождаются chgrp() на эту группу.
N>Да, тут потребуется дисциплина доступа, но это для данной ситуации явно не страшно.

Для 2. есть setgid на директорию.

https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html
On most systems, if a directory’s set-group-ID bit is set, newly created subfiles inherit the same group as the directory, and newly created subdirectories inherit the set-group-ID bit of the parent directory.

Здравствуйте, rudzuk, Вы писали:

R>Софт распространяется в виде appimage, инсталлятора нет.
Увольте предложившего распространять таким образом и наймите более годного девапса.

Здравствуйте, rudzuk, Вы писали:

R>Здравствуйте, vsb, Вы писали:

vsb>> Создайте инсталлятором папку /var/cache/myprogram и дайте ей нужные права, хоть 777 (но лучше 770 и создать отдельную группу для пользователей вашей программы).

R>Софт распространяется в виде appimage, инсталлятора нет.

добавте в образ appname-config.sh, если еще не добавили. так все делают. из известных например mysql и postresql. надо было с самого начала начинать с этого скрипта/бинарника. у вас ни одного что ли опытного пользователя линукс нет?